serverless-express VS crisp-react

After building out a GPT powered endpoint, I wanted a low cost way of hosting it. At the time, I came across the serverless-express project https://github.com/vendia/serverless-express/tree/mainline, but no actual starter kits that would allow me to deploy it.

It’s all handled using https://github.com/vendia/serverless-express

Amplify gives an option of using a template and linking the API Endpoint with the Lambda and a connected DynamoDB table. I selected the template, Serverless Espress, which provided a lot of code in the template, though the majority of it felt overly bloated for what was effectively CRUD functionality.

With that in mind, the goal of this library is to be as lightweight as possible. There are other libraries out there that can handle express -> serverless mutation. See Serverless Express for that. If you want to rewrite as little code as possible, that is your best solution. With that being said, if the sole purpose of express is middleware and is only hosting a one-endpoint GraphQL server, I recommend rewriting to utilize this library.

To get Express to run on AWS Lambda the Node http stack needs to be emulated, or a full-blown HTTP/TCP server needs to be started and proxied to. Each of these workarounds require a ton of code from libraries like serverless-express.

Express is a framework/software. Lambda is compute. You can run express in Lambda. Ive done this and it was great. Check out https://github.com/vendia/serverless-express. The cool thing is that it's portable - you can build for one compute environment, and move it to another if it doesnt suit

Yea its fine use https://github.com/vendia/serverless-express since you are using express

Serverless Express - library that makes our "plain" NestJS API play nicely with Serverless

Some people like the Unix philosophy of "Do one thing and do it well" for Lambdas, others would build a monolithic app using a single Lambda with built in "routes". Both designs have pros and cons.

If TypeScript doesn't put you off (it's really a good choice for both backend and frontend), have a look at Crisp React.

Ability to handle a monorepo with 2 builds depends on a particular monorepo. For example, Crisp React (https://github.com/winwiz1/crisp-react) has 2 logical projects: server (https://github.com/winwiz1/crisp-react/server) and client (https://github.com/winwiz1/crisp-react/client). Each project can be built separately. And this is the website built (both projects used) and deployed automatically by Cloudflare Pages: https://jamstack.winwiz1.com

You can use Crisp React to split a monolythic React SPA into several SPAs. Each SPA will have its own instance of React Router that is aware of the several pages that belong to that particular SPA.

The VM resorces such as CPU and memory should be used to handle API calls and return data. That's in case some webpages are dynamic and require API data. All static assetts including images are better to be served by a CDN. Which means your VM will serve the static assets to the CDN data centers and not to end users. Example: this website or that.

For deployment you can use Docker multi-staged build to ensure the backend run-time environment doesn't contain the client build-time dependencies e.g. client/node_modules/. It improves security and reduces container's storage footprint. An example for React client and node server is here. Although this has nothing to do with code/types sharing.

https://github.com/winwiz1/crisp-react/blob/master/docs/benc...

Tailwind is powerful, consistent and comprehensive but again the advantages come not without a drawback: In order to use it effectively one needs to learn/memorise yet another CSS. I have better things to do and think it's more efficient to use a set of CSS management approaches:

Crisp React uses the same Express server in production and debugging (for full stack builds only).

The alternative approach is to use not many but several tools in a manner that utilises advantages while minimising drawbacks. You can read about it here, scroll down to the CSS bullet.

You can have Login/authentication SPA, Reporting SPA, etc. Each SPA does its own routing as demonstrated here.