←back to thread

82 points jaysylvester | 2 comments | | HN request time: 0.399s | source

Citizen is a web application framework I started building years ago when I was first learning Node. I've added features and improved stability/performance continuously and finally decided it was worthy of 1.0 status.

I think it might appeal to devs like me (old guys) who came up on app servers like ColdFusion, .NET, PHP, etc. and prefer the server do the heavy lifting. It doesn't dictate anything about your front end, and instead tries to be as flexible as possible in providing whatever output the client might need, whether it's a single fully-rendered HTML view, partials, JSON, or plain text.

Only 2 direct dependencies for terminal commands (commander) and file watching (chokidar). Built-in functionality includes zero-configuration server-side routing, session management, key/value store (cache rendered views, controller actions, objects, and static files), simple directives for managing cookies, sessions, redirects, and caches, and more.

It's been in continuous use on at least one site that receives hundreds of thousands of page views per month, running months at a time without the process crashing. Fairly stable.

Appreciate any comments/feedback/contributions.

1. Commander_lol ◴[] No.41865463[source]
Congrats on launching your 1.0!

As someone else that is doing something with a remarkably similar sales pitch for the same sorts of reasons, it's interesting to see a very different approach to the one that I've taken.

Are there any particular use cases that you've encountered that wouldn't be a particularly good fit for Citizen? (i.e. do you have an anti-pitch?)

It would be interesting to know what considerations you've made for a few other points I might expect from an app server:

- What's the story around scaling the number of instances of a Citizen app beyond 1? There are a few things like sessions or cache that are stored in globals

- Similarly, how configurable are things like (e.g.) session storage? If, for example, I wanted to use cookies or store sessions in my database

- Is there any prescriptive way that you're supposed to interact with external data? By this I mean, you've got some file structure for storing models, but it's unclear what the expected usage is

I'm looking forward to seeing how this evolves!

replies(1): >>41866088 #
2. jaysylvester ◴[] No.41866088[source]
As you've noted, citizen is clearly written to handle pretty much everything within the application server itself, which stems from my own particular use cases.

I suppose that's my anti-pitch: citizen caters to apps that can run comfortably on a single instance and accommodate storage within that instance, or have a web server in front that can distribute clients across multiple app servers and keep each client on the same instance so as to preserve user sessions across requests.

Now that I consider it feature-rich enough for general use by other devs, I'm thinking about how it could be expanded to accommodate external storage solutions and make the app server stateless.

I opened this months ago and it directly addresses your point:

https://github.com/jaysylvester/citizen/issues/120

The same question applies to citizen's built-in caching, but if I uncouple that from the app server, I have to ask why the dev wouldn't just use a third-party caching solution instead.

As for external data, I deliberately left models wide open and un-opinionated. They're modules you can put anything into. For my own apps, I use node-postgres, and my models contain all my SQL queries and interact directly with the database. citizen doesn't interact with the model in any way besides storing the module in the global scope so it can be retrieved without importing it (which I do to support hot module reloading).

Curious to see what you've been working on and your approach.