Ask HN: How is your JavaScript based backend organized?
5 comments
- Data migrations: Knex.js
- Deployment: Every repo contains a "deployment" directory with a dir each for "staging" and "production" with all of the Kubernetes manifests (deployment, service, configmap etc.) necessary. Everything except secrets, which are managed manually. These declarative configs get applied to our cluster by gitlab-ci.
- ORM: You're probably not going to like this as a rails guy, but I've moved away from full, ActiveRecord-style ORMs. They don't work particularly well for my use cases and I enjoy the flexibility and control a thinner library like knex gives me.
- Background tasks: These are implemented as standalone apps running in our cluster, either as deployed workers subscribed to a Google Cloud Pub/Sub queue or scheduled jobs deployed using the Kubernetes cronjob functionality.
APIs: Express for basically everything HTTP. A lot more of our stuff is moving to PubSub for inter-service communication.
- Front-end templates: Everything is server-side rendered React. We run separate front and back end servers, scaled independently. The Kubernetes ingress handles routing to the SSR/React app and API app as necessary.
- Deployment: Every repo contains a "deployment" directory with a dir each for "staging" and "production" with all of the Kubernetes manifests (deployment, service, configmap etc.) necessary. Everything except secrets, which are managed manually. These declarative configs get applied to our cluster by gitlab-ci.
- ORM: You're probably not going to like this as a rails guy, but I've moved away from full, ActiveRecord-style ORMs. They don't work particularly well for my use cases and I enjoy the flexibility and control a thinner library like knex gives me.
- Background tasks: These are implemented as standalone apps running in our cluster, either as deployed workers subscribed to a Google Cloud Pub/Sub queue or scheduled jobs deployed using the Kubernetes cronjob functionality.
APIs: Express for basically everything HTTP. A lot more of our stuff is moving to PubSub for inter-service communication.
- Front-end templates: Everything is server-side rendered React. We run separate front and back end servers, scaled independently. The Kubernetes ingress handles routing to the SSR/React app and API app as necessary.
expressjs (and some plugins for input parsing, compression, etc..) for HTTP server and API.
socket.io for websockets (easy API and great fallback functionality).
(I think both will serve you well with the default settings. you won't need to worry about scaling until you have hundreds or thusands of req/sec)
for deployment IMO it's always better to use docker, and it's easy to learn the basics in one afternoon. (for small apps: on gitlab/github push -> do gitlab-ci/travis-ci docker build + api testing + run deploy script)
ORM - you can probably find one for every DB out there, but I prefer to write the queries myself.
Data migration - I'll probably work directly with the DB... depends on the scale of the app
socket.io for websockets (easy API and great fallback functionality).
(I think both will serve you well with the default settings. you won't need to worry about scaling until you have hundreds or thusands of req/sec)
for deployment IMO it's always better to use docker, and it's easy to learn the basics in one afternoon. (for small apps: on gitlab/github push -> do gitlab-ci/travis-ci docker build + api testing + run deploy script)
ORM - you can probably find one for every DB out there, but I prefer to write the queries myself.
Data migration - I'll probably work directly with the DB... depends on the scale of the app
Little bit vague but here goes:
technology: Loopback (based off of ExpressJS, which is based off of NodeJS, which is based off of Javascript, wew....)
by organised, if you mean dir structure then the top levels are /helper-scripts (bash), /models (resource type property JSONs and JS scripts for RPCs), /server (entrypoint points, middleware, etc.), and a few misc files.
if by organised you mean source control, then it's bundled with the same repo as my uis, lb, etc. one repo => one app is a golden rule.
what other meanings of "organised" could you mean? Design methods maybe?
technology: Loopback (based off of ExpressJS, which is based off of NodeJS, which is based off of Javascript, wew....)
by organised, if you mean dir structure then the top levels are /helper-scripts (bash), /models (resource type property JSONs and JS scripts for RPCs), /server (entrypoint points, middleware, etc.), and a few misc files.
if by organised you mean source control, then it's bundled with the same repo as my uis, lb, etc. one repo => one app is a golden rule.
what other meanings of "organised" could you mean? Design methods maybe?
Looks pretty cool. Wish it had support for a relational database though.
Now, I'm sure there are Rails like frameworks for full-stack Javascript development.
I'd love to hear about how you organize things like: - Data migrations. - Deployments. - ORM - Background tasks. - APIs - Multiple language support in front-end templates.
etc..etc..
Do most people roll their own back-kend framework?
As an aside, whats the state of server-side template rendering? Is that industry practice?