TSBOARD (builder de comunidade open source escrito em TypeScript)
(github.com/sirini)O que é o TSBOARD?
- TSBOARD significa Type Safety BOARD, sendo um builder de comunidade e sistema de fórum escrito em TypeScript.
- Ele usa o runtime Bun, já apresentado aqui no GeekNews, e estruturou o backend com o framework web ElysiaJS. Graças a isso, opera mais rápido do que motores de fórum convencionais.
- No frontend, foram usados Vue e Vuetify. Mas como o senso estético do desenvolvedor deixa a desejar, escrevi este post com a esperança de que, no futuro, talvez possa contar com a ajuda de designers generosos. (+ e claro, também preciso da ajuda de desenvolvedores generosos!)
Por que foi criado?
- Comecei a programar para a web com
PHPe sou um desenvolvedor que viveu a era do Zeroboard e do GnuBoard. - Minha última lembrança de JavaScript era de uma linguagem que, sem
jQuery, parecia um lixo (...). - Mas acabei me encantando, ainda que tarde, com as melhorias contínuas dos padrões, o surgimento do
Node.jse o TypeScript da Microsoft. (na verdade, acho que me encantei tarde demais) - Então quis voltar a criar um programa web e, principalmente, escrever o clássico fórum que eu sempre fiz usando apenas TypeScript.
- Além disso, resolvi fazê-lo porque queria criar algo (já que estava fazendo mesmo) fácil de usar, mais rápido e com operação mais segura.
Vantagens exclusivas do TSBOARD
- O TSBOARD é escrito inteiramente em TypeScript tanto no frontend quanto no backend, o que garante ao máximo a segurança de tipos. (nada é perfeito, mas esse foi o ponto em que mais me concentrei)
- Para quem já fez desenvolvimento full stack com base em
Node.js, é um design fácil de entender e de aplicar imediatamente. Como eu mesmo fui aprendendo tudo desde o começo enquanto construía, consultei muitas boas práticas de outras pessoas. - Ele já inclui todos os recursos necessários para criar sites de comunidade de pequeno e médio porte. Durante o desenvolvimento, consultei como referência comunidades coreanas bastante conhecidas, como Clien, Quasar Zone, Giggle Hardware e também a mais recente Damoang.
Também há desvantagens.
- O runtime Bun não funciona corretamente em CPUs virtuais. Em hospedagens de servidor virtual com preço acessível, é difícil aproveitá-lo adequadamente. Como o TSBOARD também depende do Bun, o mesmo vale aqui.
- O TSBOARD usa a abordagem de Client Side Rendering. Como alguém que ainda gosta de PHP, o termo Server Side Rendering era até mais estranho para mim. Há vários prós e contras, mas antes de tudo eu queria experimentar uma abordagem nova (para mim), e como desenvolvi o TSBOARD com o objetivo de reduzir a carga do servidor, isso certamente pode ser visto como uma desvantagem para algumas pessoas.
- Na verdade, já faz mais de meio ano que comecei o desenvolvimento, mas ainda há muitas limitações, a ponto de só agora conseguir finalmente apresentá-lo. Espero poder superar essa desvantagem com a ajuda das pessoas generosas que encontrar pelo caminho.
Encerrando: sonhando com o dia em que comunidades famosas adotarão o TSBOARD
- Ao ver o GnuBoard passando de PHP para Python, senti que os programas web também continuam tentando coisas novas. O mesmo vale para o Rhymix, que nasceu do XE. A web continua dinâmica, e o desenvolvimento também.
- Eu também quis deixar esta apresentação com o desejo de contribuir, ainda que modestamente, para o ecossistema web por meio do projeto TSBOARD.
- Sonho com o dia em que um novo site de comunidade que venha a nascer adotará o TSBOARD. rsrs
Obrigado por ler até aqui!
21 comentários
Talvez não ajude muito deixar mais um comentário em uma postagem de cerca de 2 semanas atrás rsrs,
mas, enquanto pensava em como refletir os feedbacks sobre SEO que recebi no GeekNews,
implementei o
sitemap.xmlpara aplicar a otimização para mecanismos de busca e estou deixando este comentário para compartilhar o conteúdo!Resumindo: os mecanismos de busca acessam
robots.txt>sitemap.xmle, por fim,coletam os dados no caminho
https://tsboard.dev/tsapi/seo/main.html(página de exemplo).Quando o usuário entra por uma busca, fiz com que ele possa acessar novamente o site original por meio dos links dessa página.
Você pode conferir os detalhes no link abaixo!
https://tsboard.dev/board/free/18
Eu também estava pensando em rodar com bun um projeto que faço como hobby, mas fiquei surpreso ao saber que ele não funciona direito em uma CPU virtual. E, na hora de se cadastrar, como estava escrito que a condição da senha era letra maiúscula, achei que não precisava incluir minúsculas, mas fui pego nessa kkk. Acho que seria melhor escrever maiúsculas e minúsculas.
Só por precaução, estou deixando uma resposta. Quem estiver considerando o runtime Bun não precisa mais se preocupar com problemas de funcionamento em CPUs virtuais...! Testei na versão 1.1.31 e confirmei que funciona sem problemas. :)
Ah, muito obrigado pelo comentário, e com certeza vou corrigir também a parte das condições de senha que você mencionou. hahaha
Quanto ao Bun, eu também não diria que usei a fundo, mas tive muitas experiências surpreendentes com ele em vários sentidos enquanto usava. Também passei por muitas situações em que algo que funcionava normalmente no Node.js, por algum motivo, não funcionava nele — entre elas, por exemplo, o problema de não oferecer suporte à opção
recursive: trueao criar pastas. Ao mesmo tempo, também vi muitos aspectos de uma obsessão impressionante por velocidade (e foi justamente por isso que acabei gostando ainda mais dele).Agora chamam de Bundows, e o runtime do Bun já tem suporte oficial no Windows, mas antes da versão 1.1 isso não existia, então era preciso rodá-lo no WSL2. Sobre o funcionamento em CPU virtual que você mencionou, é bem provável que o Bun continue sem oferecer suporte no futuro também. Eles até disponibilizam uma distribuição (baseline) para CPUs que não suportam instruções AVX2, mas a falta de suporte a CPU virtual — talvez por ser uma limitação do Zig, a linguagem usada no desenvolvimento do Bun — continua sendo uma situação decepcionante em vários aspectos. Minha impressão ao usá-lo foi basicamente esta: para ganhar velocidade, parece que o Bun também abriu mão de algumas coisas.
Caso algum futuro usuário de Bun veja este comentário, só queria acrescentar mais uma coisinha: apesar de várias limitações, o Bun ainda é uma opção muito atraente. Principalmente se você escolher o ElysiaJS como framework web, acho que pelo menos no quesito velocidade não haverá do que sentir falta. Se eu tivesse que voltar ao início e escolher o runtime de novo... pensaria um pouco mais, mas no fim, apesar de vários problemas, acho que ainda escolheria o Bun. Essa obsessão quase fanática por desempenho, e a postura de desafiar um ecossistema de runtimes JS que já parecia ter uma resposta pronta, mexem com a gente de algum jeito. hahaha
Enquanto eu olhava o código no GitHub, fiquei com uma dúvida e deixo aqui minha pergunta.
Pessoalmente, fiquei muito impressionado em ver surgir um sistema de fórum baseado em TS que eu gostaria muito que existisse!
A configuração de chave estrangeira foi aplicada na atualização v0.8.40! https://tsboard.dev/board/free/18
Ah, obrigado pelo comentário!
Quando você fala de definir relacionamentos, imagino que esteja se referindo ao fato de as chaves estrangeiras não estarem configuradas! Não houve um motivo específico para isso; eu estava pensando em configurar quando a estrutura das tabelas estivesse mais ou menos definida, mas acabei lidando com outras coisas no meio do caminho e ainda não consegui aplicar isso até agora. Como as dependências entre as tabelas do TSBOARD e as colunas de referência já estão relativamente estáveis, vou configurar as chaves estrangeiras e tentar mudar para uma forma que garanta melhor a integridade!
Cheguei a considerar NoSQL por um momento... mas havia coisa demais para aprender primeiro, desde a linguagem TypeScript até Vue e Node.js/Bun, então decidi não mudar. Bancos de dados relacionais já são antigos, com toda a longa história que têm, mas também fiquei pensando se não existe um motivo para ainda serem úteis e amplamente usados em tantos lugares. No momento em que escrevo este comentário, penso assim, mas se no futuro surgir alguma necessidade, talvez eu possa considerar algo como MongoDB. haha
Pessoalmente, acho surpreendente que ainda não existisse um fórum baseado em TypeScript, mas talvez isso também seja só uma questão de tempo. Espero que surjam muitos outros projetos com um estilo diferente do TSBOARD! haha Obrigado pelo comentário!
Sinceramente, como eu estava pensando naqueles fóruns antigos em PHP, não esperava muita coisa, mas mudei de ideia depois de ver o site de demonstração (https://tsboard.dev). A qualidade é boa demais.
Acho que esses pontos podem ser importantes!
O editor foi implementado por você mesmo? Caramba. Imagino que você tenha usado algum motor de editor (?), mas dá para sentir um artesanato impressionante nisso.
Obrigado pelo comentário! Fico ainda mais grato por você ter visto com bons olhos a qualidade do site tsboard.dev. haha
Sobre o suporte a SSR que você mencionou, preparei um roadmap dividido em duas etapas, e pretendo aplicar primeiro medidas complementares; depois, em versões futuras, desenvolver misturando adequadamente as abordagens de CSR e SSR. Para otimizar um pouco mais o SEO mantendo um bom nível de desempenho, acima de tudo eu também preciso aprender mais, então acho que vou precisar de um pouco mais de tempo. Espero que, se eu continuar sem desistir, eu também possa conhecer outros desenvolvedores generosos, aprender mais rápido e talvez até receber ajuda. haha
No caso de usuários não autenticados, quando criei o TSBOARD isso não foi considerado para reduzir o tempo de desenvolvimento e manter a simplicidade do design, mas vou pensar um pouco mais sobre isso! No momento em que estou deixando esta resposta, se for preciso considerar não membros, seriam necessárias muitas mudanças, então por enquanto isso parece difícil. ^^;;;
O editor foi montado peça por peça com base no editor tiptap, e acabou consumindo muito mais tempo do que eu esperava. Pela minha lembrança antiga, acho que era o CKEditor...? Parecia que antes dava para simplesmente pegar algo assim e usar, mas hoje em dia é preciso montar tudo peça por peça, como se estivesse montando Lego. T.T Além disso, acabei penando ainda mais para integrar as funções do TSBOARD. Enquanto desenvolvia, cheguei a pensar que seria ótimo se alguém simplesmente fizesse esse editor para mim haha... Se alguém precisar de um editor razoável(?) baseado em tiptap, acho que pode desenvolver mais rápido e com mais facilidade consultando os códigos que implementei no TSBOARD.
Tem mais gente do que eu esperava vendo isso de forma positiva, a ponto de eu achar um desperdício o tempo que passei pensando se deveria ou não escrever o texto de apresentação. O TSBOARD ainda tem muitas limitações, mas conto com vocês!
Comecei a desenvolver com PHP, e esta também é a época em que estou tentando bastante coisa por ter me encantado com TypeScript.
Fico feliz de sentir uma certa afinidade.
Prazer em conhecer! Por acaso eu também estou seguindo uma jornada parecida. haha Fico pessoalmente triste porque a linguagem PHP ainda apanha aqui e ali até hoje, mas depois de usar TypeScript, acho que talvez esteja tudo bem ela apanhar um pouquinho. haha Espero que você também faça muitos projetos divertidos com TypeScript, yeppyshiba. :)
Muito incrível 👍
Muito obrigado!! Ainda é um projeto com muitas limitações, mas fico feliz que você o tenha visto com bons olhos. haha
Vou continuar trabalhando ainda mais para melhorá-lo, para que, quando chegar o dia em que você precisar do TSBOARD, eu possa recomendá-lo com confiança. :)
Era algo que eu sentia falta... obrigado.
Muito obrigado por deixar um comentário! Se um dia você precisar de um programa web parecido com o TSBOARD, espero que se lembre dele e possa testá-lo. Vou continuar trabalhando duro para deixá-lo cada vez mais fácil de usar quando você precisar!
Nossa...! Lembro do fórum sirini da época do PHP, faz realmente muito tempo.
Na época, eu até desenvolvi skins para o Sirini Board e também reportei vulnerabilidades de segurança; espero que você esteja bem :)
O que senti olhando o código é que o código do lado do servidor tem bastante cara de PHP hehe (código JS com cara de PHP?)
Como outra pessoa comentou, se for CSR, existe a desvantagem de ser menos favorável para SEO e afins.
Acho que seria ótimo se esse ponto fosse bem complementado hehe
Ah, então você era a pessoa generosa que me ajudou no passado! Fico feliz em reencontrá-lo assim hahaha
Além disso, naquela época e ainda agora, fico com vergonha porque parece que só faço coisas meio triviais, o tipo de coisa em que qualquer um pensaria. ^^;;
Como você comentou, o código de backend tem bastante influência do estilo PHP hahaha. Eu também, às vezes, penso "será que aquela função que eu usava no PHP não existe em JS?" e acabo procurando toda vez, ou então dou nomes parecidos para as funções. Acho que, à medida que eu me acostumar mais com código JS/TS e for refatorando, isso pode melhorar ainda mais. Hahaha
Na parte de SEO, como você disse, preciso complementar isso. Pelo que pensei rapidamente, seria adicionar outras páginas estáticas, como RSS, e vou tentar algumas coisas.
Aliás, é realmente surpreendente e gratificante saber que existe alguém que se lembra de mim da época do PHP4! Na verdade, pensei muito se deveria escrever este post ou não. Hahaha;; Vou me esforçar para poder ajudar, ainda que um pouquinho, mais pessoas. E deem muito carinho ao TSBOARD também!
Deixando um comentário porque fiquei com uma dúvida ao ler o post. (Não cheguei a ver o código)
Queria entender por que o backend não foi desenvolvido para ser compatível com Node.js (o desempenho fica ruim demais para compensar as desvantagens que você mencionou?)
Se for CSR, como vocês pretendem lidar com SEO? Acho que, para uma comunidade, também é preciso se preocupar com o tráfego vindo de buscas.
Olá! Obrigado por deixar um comentário. (Na verdade, achei que isso fosse acabar soterrado na indiferença, então fiquei emocionado.)
Eu também pensei bastante nas questões que você levantou, então ficaria feliz se você lesse só como uma perspectiva possível.
Ah, e só como referência: depois do PHP, eu nunca mais continuei com desenvolvimento web na vida real nem uma única vez. Como também não acompanhei a era da revolução do Node.js nem quando o React mudou o mundo web, talvez haja aqui uma perspectiva um pouco diferente do habitual. rs
Quando comecei a desenvolver o TSBOARD, eu parti do pressuposto de que já existiria alguma solução famosa baseada em Node.js (que eu não conhecia), seja fórum, blog ou algo parecido com o que eu queria criar. Como mencionei no começo, eu não tinha motivos para fazer desenvolvimento web no trabalho e também nunca tinha feito algo que pudesse chamar de side project, então acabei pensando assim ainda mais naturalmente. Eu imaginava que certamente já devia existir alguma coisa baseada em Node.js, então não faria muito sentido eu criar mais uma do zero. Já que eu ia aprender algo novo mesmo, decidi fazer com base em Bun, e foi assim que cheguei até aqui.
Pensando em performance, sinceramente, para o tipo de site de comunidade pequena que eu tinha como objetivo (menos de 10 usuários simultâneos), eu acho que Node.js seria mais do que suficiente. Antes de avaliar Bun, eu também testei uma base com Node.js + Hono, e, na minha opinião, não havia problema algum. Mas a performance esmagadora que o Bun apresentava, junto com a performance do ElysiaJS sobre ele, me impressionaram de verdade, e eu não queria abrir mão disso. Como eu acreditava que já existiria algum fórum excelente feito por outra pessoa com base em Node.js, pensei que, para competir com esse fórum imaginário, eu precisaria de uma performance ainda maior. No fim, acabei abrindo mão da compatibilidade com Node.js e projetando tudo de forma dependente de Bun. (Hoje me arrependo um pouco. Pelo visto não existe um fórum famoso baseado em Node.js como o GnuBoard, Rhymix ou XE. Será que eu simplesmente não encontrei??)
O que você disse está totalmente certo. Para atrair tráfego de busca, no fim das contas o crawler do Google precisa ler o conteúdo e conseguir fazer a correspondência de pesquisa. Essa parte eu ainda não implementei, mas estou pensando que, se o usuário quiser, talvez seja possível expor os conteúdos mais recentes separadamente em formato estático, como se fosse a disponibilização de um feed RSS. Também penso que, se houver exposição externa em formato JSON, talvez os agregadores consigam atualizar os dados com mais facilidade. Vou refletir mais sobre isso. (Eu tinha pensado em RSS, mas hoje em dia quase ninguém usa isso, né?? Acho que fiquei tempo demais longe da web T_T)
Independentemente das medidas compensatórias para SEO, o motivo de eu ter ido de CSR foi querer reduzir de forma mais agressiva a carga no servidor. No caso do site Damoang, que surgiu recentemente (não sei se posso citar abertamente o nome de uma comunidade assim), pelo que sei, a carga de tráfego e a pressão sobre o servidor também são consideráveis. Pensando na ideia de um community builder, SEO é importante, claro, mas achei que primeiro precisava resolver aquilo que está diretamente ligado a custo. Por isso priorizei CSR. Como alguém que ainda ama PHP, SSR na verdade é até mais familiar para mim, mas você pode entender essa escolha como algo na linha de: se o cliente usar de forma mais ativa seu poder de computação, talvez o servidor recupere um pouco mais de folga.
Espero que isso tenha esclarecido um pouco suas dúvidas. Além disso, as escolhas que fiz têm prós e contras bem claros, então na verdade eu não acho que o TSBOARD seja a resposta certa. Foram decisões tomadas considerando vários trade-offs e dentro dos limites das minhas reflexões ainda curtas sobre o assunto. Se no futuro o TSBOARD passar a ser usado com mais frequência, sempre posso mudar de ideia e tentar outras abordagens. rs
Como a arquitetura já foi projetada para CSR, para mudar para SSR provavelmente seria necessário um trabalho quase no nível de reescrever tudo do zeroT_T
Os crawlers de busca recentes até vêm melhorando um pouco no suporte a JS, mas... ainda assim, acho difícil alcançarem o nível de HTML puro.
Em navegadores comuns, poderia continuar com CSR, mas no caso de bots de busca (GoogleBot, Yeti etc.), talvez desse para usar uma abordagem com SSR.
Pessoalmente, acho que esse tipo de abordagem é mais um quebra-galho temporário e, no fim, para dar um bom suporte a SEO, SSR não seria a resposta certa?
Mesmo sendo CSR, no fim das contas, quando o volume de requisições aumenta, a carga no backend também aparece, então parece que o melhor caminho é reduzir essa carga com um bom projeto de cache e vários outros mecanismos ^^;
No caso do TSBOARD, como você mencionou, tudo foi feito com base em CSR, então pelo menos na versão v1.y.z parece que teremos que trabalhar com o critério de CSR only. Para tentar complementar um pouco, como a estrutura faz com que todos os posts apareçam na primeira tela, talvez dê para aplicar SSR só na primeira tela, ou então, como você disse, adicionar uma página separada para que os bots possam rastrear o lado de plain HTML! Vou tentar refletir essas melhorias na linha de versões v0.9.z!
Ah, só comento isso porque fiquei um pouco preocupado que algumas pessoas possam pensar "o TSBOARD não aparece em buscas porque usa CSR!": no caso do Googlebot, dizem que ele já evoluiu a ponto de conseguir capturar também o conteúdo de sites feitos com CSR! (Só porque é o Google...?) É claro que é uma abordagem menos favorável para SEO, mas não é que seja totalmente impossível, então acho que não precisam se preocupar tanto.
Além de CSR e SSR, deve haver também abordagens em algum ponto intermediário, então vou pensar mais a respeito e montar também um roadmap para a v2.0.0 com o objetivo de melhorar o SEO. (Embora isso ainda esteja um pouco distante haha.) Obrigado pelos conselhos, e apesar de ser um projeto ainda com muitas limitações, conto com vocês com o TSBOARD!