
Ask HN: How is your JavaScript based backend organized? - horsecaptin
I come from a Ruby on Rails background. It is great - working with Rails has had two huge upsides for me. First, the framework means there is a good way to do almost everything. Two, it makes me think about problems and the solutions generally fit elegantly into the framework.<p>Now, I&#x27;m sure there are Rails like frameworks for full-stack Javascript development.<p>I&#x27;d love to hear about how you organize things like:
- Data migrations.
- Deployments.
- ORM
- Background tasks.
- APIs
- Multiple language support in front-end templates.<p>etc..etc..<p>Do most people roll their own back-kend framework?<p>As an aside, whats the state of server-side template rendering? Is that industry practice?
======
dfcowell
\- 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.

------
assafmo
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

------
SamUK96
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?

------
niftylettuce
[https://lad.js.org](https://lad.js.org)

~~~
mjhea0
Looks pretty cool. Wish it had support for a relational database though.

