If so, where/how and what do you like about it?
Nitrogen Web Framework is the fastest way to develop interactive web applications in full-stack Erlang.
If so, where/how and what do you like about it?
Nitrogen Web Framework is the fastest way to develop interactive web applications in full-stack Erlang.
I sure have, for tasks ranging from straight CRUD applications to a UI for SaltStack. Mostly, these days, I aggregate data and do a lot of ETL work. (I cannot stress enough how big a win Erlangās concurrency is for transformations!)
I picked Nitrogen because:
Itās possible to have a rich interactive UI without touching Javascript at all. There is nothing about programming JS that I enjoy.
Nitrogen is agnostic with regards to the model ā in other words, itās possible to use whatever backends and libraries are appropriate without fighting the framework. For instance, I almost always prefer hand crafted SQL to an ORM library like Ecto.
Emphasis is on code and not configuration (or ā gasp ā convention). This translates into (maybe) more code but also a lot less āmagicā than Iāve encountered with other frameworks.
I emphasize these points in part because I donāt really write āweb applications.ā Almost all the work I do involves teeing up data for use by other applications and, honestly, most of it could be done without a web component at all. However, itās 2021 and my users expect a web UI. I usually start with a DB schema, some SQL, maybe a few REST calls, and some bespoke transformations. Once thatās working via the REPL, tacking on the UI with Nitrogen is a couple of page modules and ErlyDTL templates.
Iāve been using Nitrogen long enough that I have a reusable libraries providing user and group management, authorizations, AD integration, auditing, PostgreSQL interactions, and so on. Once the business process is defined and implemented, the infrastructure-y bits are trivial.
In conclusion: most of my effort should be data modeling and writing the appropriate SQL. If Iām spending time trying to figure out how to update an HTML element with JS, thatās not actually getting the work Iām being paid for done.
Iām really interested in hearing other use cases.
I sure have! (Iām the project lead for it, so Iād hope so)
@bunny pretty much covered most of why I like it.
Iāve been using Nitrogen full time for about 10 years now, my primary use is for a web application for running sports leagues and tournaments that a few years back was acquired by SportsEngine/NBC Sports, but I have a handful of various contract projects built with it over the years, ranging from in-house Dropbox clones, to Truck scheduling to Telemedicine.
For those who have beef with Nitrogen not having an ORM, I have a light SQL-based framework called sql_bridge that has some very light ORM tools and is largely designed to run with Nitrogen.
Erlang really is a criminally underused language for front-end development.
I have made things deployed with nitrogen/n2o, it was fantastic for making a client-sided-feeling app driven from the server (think Phoenixās Live pages thing now, but a bit more powerful and lower level), and this was even back in the days when something like GMail was a ānew thingā. ^.^
That is so bizarre. I have been (slowly) working on the same thing, also in Nitrogen. Had no idea that parts of SportsEngine were running Erlang/Nitrogen.
Whoa! Thatās nuts. The core SportsEngine product is obviously not in Nitrogen, but my small product that specializes in beach volleyball leagues and tournaments (BracketPal.com) is.
I realize Iām the competition, but honestly, unless youāre specifically targeting the beach volleyball space, I donāt see it as that.
Iām curious if youāve got an early beta (or if youād rather fly under the radar, thatās fine too - I also I tried my best to fly under the radar for a bunch of years), Iād love to see it.
If youād rather discuss this privately as well, feel free to hit me up on the Erlang slack or discord (Iām āchopsā on there both). Thatās fascinating to me that such a niche framework on a niche language would attract two products in the same market.
Feel very much the same as @bunny. I tend to build applications in SQL first. Relational databases are IMO the appropriate choice for a general-purpose data store about 90% of the time. I use a lot of stored procedures. Once I have my DB schema and stored procedures implementing all the functionality, then I build the UI on top of that. I donāt use ORMs. I have found building a web UI for my database to be very straightforward using Nitrogen (and I consider myself far from an Erlang expert ā I like Erlang but have not used it regularly enough to become really fluent in it). One of my first managers used to say āget the data model right and the application writes itselfā and over the past 30 years in IT and software development I have found that to be almost always true. What I like about Nitrogen is that it doesnāt force you into any particular backend model so it works well with this approach.