Node developers, what's your rapid development stack?
In the spirit of brining a few ideas to production as soon as possible, I'm curious what others here are doing.
In industry, I've gone proper with either Go/Express with React using typescript. But I've noticed that there is speed complexity in this although it works well for larger teams and staying organized. But maybe it's an over-optimization and .pug and plain javascript is all I need to build something of "value" quickly.
Thanks for your thoughts!
Great question. Nowadays on the frontend side I use React, even for simpler things, because I will help me save time with boilerplate / initial configuration or even project structure.
On the backend side, I am stuck with: Expressjs, Sequelize and Postgres, sometimes MongoDB
My last projects are made with Sveltekit + supabase + netlify.
Super efficient
In Today's Era, there are a ton of programming dialects that will presumably shape our future. In any case, when we begin getting the hang of programming we start with the C language then continue on toward C++ or one of the numerous other programming dialects. However, today I will discuss the most famous programming language which is known as Java. The prominence of Java can be credited to its flexibility as it very well may be utilized to configuration altered applications that are light and quick and fill an assortment of needs.
Read more: https://bit.ly/3E790fu
Hi @Whoof 👋
I built (Edith & Nous)[https://www.edithetnous.com/] (my first product) with CRA and a simple express server, when it was only a simple MVP.
As we expanded the product, we added Sanity and some other things, but it's still one simple server and plain old JavaScript/Node.
I think going simple to test your idea is the best way to go, do not overoptimize your tech stack, you'll have plenty of time to do so when it's needed (i.e, when you grow) 😄.
Still, if you're familiar with TypeScript, Next.js is a great choice as it gives a lot of out of box tool I had to recreate when working with CRA and the typings are great for catching errors beforehand, reducing the needs for automated test while you build your value proposition first.
Thanks for the tips. I think I should give next a closer look then. If I pair it with a headless CMS, can I have the CMS on the same node server that serves the app? And can I customize endpoints simply enough? I worry the CMS will be a pain to keep extending.
I guess you can have the headless CMS on the same node server with a bit of tooling, but I'd advise against it. You don't want content crashes to crash your value proposition.
Actually, I'd avise against using headless CMS at all if you can avoid it. To be honest, the choice of using Sanity wasn't made by myself and I find it a bit troublesome to always makes change for the people writing content or extending some schemas (we only use it for blogging).
IMO, marketing website should be separated from the app itself, and we are migrating to Webflow at the moment.
If you're using Headless CMS for other purposes (APIs, RSS, or whatever), it's fine though.
As a general advice, if you look for simplicity, you want to remove as much cognitive load as you can, and you want a lot of out of box tools.
Webflow solves that for content and statics apps, Next does it for the app generation.
Next.js endpoints are entirely configurable and the syntax is very close to what you're used to with express. You can also completely customise the server if you ever feel the need to (although I never had this need myself), so no worries on this side, it's really simple to use and customise 😊
To be clear are you advocating for just writing REST endpoints yourself, over using a CMS? I'm used to doing everything from scratch so don't know the limitations of the latter, but it would be nice if things could be autogenerated but also kept simple.
Does next.js bundle together with a server?
Oh, no sorry, I wasn't clear.
My point was just over using Headless CMS for SEO/Marketing content inside the app server, and not all use-cases of autogenerated content or headless CMS in general.
As marketing content is often very distinct from application work, I personally feel it's best to keep the two separated.
But by all mean, you can use CMS, it's clearly simpler than writing everything on your own 😄
For instance, we use a Webflow static website with an integrated CMS for our static SEO/blog content and we use CRA for the app. Previously, we were using Sanity with dedicated endpoints, but I had to manage the website integration and I felt it was too much time consuming, that's why I decided to split the two, and what I'm advocating for.
As I'm often not the one writing the SEO content, it's simpler to use for them and less product/tech mental load for me.
Next.js has an integrated node server that works very very well, with tons of optimisation out of the box.
Everything you need to get started is well documented in the documentation. 😊
So what did you end up doing when you split to react (for the app)? Did you rebuild the endpoints for that from scratch?
NextJS, NestJS, AWS Lambda, and a CMS like sanity.io or keystone.js (or Strapi like proup24 mentioned)
Can you extend these CMS tools enough for customized actions? For example if you want a bulk delete operation not built into the default CMS? Wondering if this can act as a full on backend substitute.
I like using their automatically generated GraphQL apis, and you can always build your own custom operations too
Check out Strapi, a great low-code backend framework for Node. I use it a lot for rapid prototyping. In the frontend I usually go for Vue and TailwindCSS.
Neat! How extendable is this? If you need custom db actions can you implement them yourself on top of this?
Sure. Strapi is a headless CMS unlike most, the framework is very very customizable and stable. It's basically a reliable replacement for the old school Node/Mongoose stack, you can also use SQL databases, TypeScript, GraphQL and much more with little configuration, and on top of that it's very easy to learn. I usually use a Strapi backend (to manage databases) along side other functional Express microservices, making easier for me design solid APIs with good layers of abstraction.