Server requirements

Keywords: #code #work

Every now and then I have to create a new server. Sometimes in Python, sometimes in Javascript (lately more Typescript), sometimes it is Go. Rarely Rails (at least lately). Over time, the following are my self-inflicted requirements for a nice server. Just putting it out here for future reference. Also, I might just create a series about creating such a server (perhaps in Golang?)

  1. Database connection/s
    • of course at least one type should be configured.
    • but possibly with choice of environments - develop on psql, testing on sqlite (for example)
      • I’ve found it quite nice to have local tests that can be run on against an in-memory sqlite DB
  2. Migration (either automatic on start, or with a simple trigger)
    • CRUD for entities, and similar things
    • NOTE that this might get tricky with ability to run against different DBs.
      • In conflict, I think we stick with the DB of our choice and migrations win
  3. /health endpoint
    • Should return something like { status: "Ok", db_ping: "43ns", version: "x.yy.zzz" }
    • The DB ping is quite useful at times (if you ping takes longer, you can directly see there’s a bit of load there)
  4. NO global variables (must I explain?)
  5. NOTHING hardcoded
    • Env variables are to be read only in the main (entry method)
    • And proper dependency injection
  6. Swagger generated with annotations, not with a large yaml/json file
    • Would love if it is a smart/er system which generates from code itself ;)
  7. One method createServer(params) should return
    • a server we can run, and
    • a shutDownServer which will gracefully shut things down
      • (optional) proper disconnection from DB as well
      • And to be called when we receive signals to die/kill
  8. Middle/After-ware which logs
    • Request arrival
      • possibility to turn on body/header logging
    • Request completion with time taken
      • possibility to turn on output logging
    • The possibility to add an arbitrary middleware
      • For example, something to add a dummy-header to the request.
  9. Unit tests
    • Anything which is NOT an api call should be testable with unit tests
      • (optional) If possible the migration method should be tested too
  10. Integration/API tests
    • All apis should be testable (/health included)
      • Test the response code, and verify with another call, but not by looking into DB.
    • Create database at start
    • Connect to database (in memory is fine too)
    • NO tests shall call endpoints directly with path.
      • They shall be called as methods of server, or server like object.
    • On test completion, shutdown the server, disconnect the database
      • a nice teardown (though our db might be in memory or temporary file)
  11. Internationalisation / Localisation
    • The request shall be able to send `Accepted-Language` header, and the response must respect it.
    • Should have some kind of localised strings file.
  12. Project shall be
    • structured to
      • entry-point.<java|ts|go|js|py>, (say main)
      • and folders like routes/, models/, controllers/, repository/ (business logic), and /services
    • with rather limited package dependency
    • compile/runnable and testable with simple commands, small script, etc.
  13. Basic auth endpoints, sessions, tokens, etc. without JWT (I personally dislike JWT)

– sillyfellow on 2023-08-06 (Sun 22:47)

← prev