postgres-websockets
scotty
Our great sponsors
postgres-websockets | scotty | |
---|---|---|
1 | 19 | |
337 | 1,689 | |
- | 0.8% | |
7.2 | 8.0 | |
6 months ago | 10 days ago | |
Haskell | Haskell | |
BSD 3-clause "New" or "Revised" License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
postgres-websockets
-
PostgREST – Serve a RESTful API from Any Postgres Database
At work, we've finally replaced a large part of a custom (mostly-)web backend with PostgREST recently, and that's quite a relief: considerably less code to maintain in that project now, and that was a rather awkward code. Something akin to PostgREST's "Embedding with Top-level Filtering" [1] had to be provided for all the tables, with OpenAPI schema and a typed API (Haskell + Servant); I avoided manually writing it all down, but at the cost of poking framework internals, and maintainability suffered. It was particularly annoying that the code doesn't really do anything useful, except for standing between a database and an HTTP client, and simply mimics the database anyway. Whenever a change had to be introduced, it was introduced into the database, the backend, and the frontend simultaneously, so it wasn't even useful for some kind of compatibility.
Now PostgREST handles all that, and only a few less trivial endpoints are handled by a custom backend (including streaming, which I'm considering replacing with postgrest-websocket [2] at some point).
During the switch to PostgREST, the encountered minor issues were those with inherited tables (had to set a bunch of computed/virtual columns [3] in order to "embed" those), and with a bug on filtering using such relations (turned out it was an already-fixed regression [4], so an update helped). Also a couple of helper stored procedures (to use via /rpc/) for updates in multiple tables at once (many-to-many relationships, to edit entities along with their relationships, using fewer requests) were added (though the old custom backend didn't have that), the security policies were set from the beginning, the frontend was rewritten (which allowed to finally switch without adding more work), so it was only left to cleanup the backend.
Not using views, since as mentioned above, database changes usually correspond to frontend changes, and the API doesn't have to be that stable yet.
Happy with it so far.
[1] https://postgrest.org/en/stable/api.html#embedding-with-top-...
[2] https://github.com/diogob/postgres-websockets
[3] https://postgrest.org/en/stable/api.html#computed-virtual-co...
[4] https://github.com/PostgREST/postgrest/issues/2530
scotty
-
haskell todo list app (beginner)
I would suggest checking out scotty for the http server - it uses warp by default, and is very beginner-friendly.
-
HLS issues an error for Setup.hs and Spec.hs (using hspec-discover)
Here's the current commit I'm working with: https://github.com/scotty-web/scotty/commit/3ed8586c046b46dc42740e8ac2e7fe712e84191d
-
School of Haskell: Basics
If you're not a fan of the ruby-on-rails / swiss army knife approach that IHP takes, check out Scotty. Add Lucid for Html rendering, and Selda for Postgres. (There are other options for any of these tools if you prefer)
- Scotty (simple web routing) https://hackage.haskell.org/package/scotty
-
Use Haskell from Nodejs
Writing a Haskell webserver (maybe using scotty) and call it from node.
- Programming language comparison by reimplementing the same transit data app
-
How to change state in a webserver application
I've been looking for this as well, and found the globalstate.hs example in the scotty github repository. It uses a ReaderT of a TVar and shows how to update or read shared state in memory.
-
Suggestions for "dashboard" graphics libraries?
I've found htmx and hyperscript talking to scotty to be an easy way to get something like this going while retaining the joys of Haskell on the backend and avoiding the pains of Haskell on the frontend.
-
Web development in Haskell
Finally, to add my opinion in the context of some other posts: I'd suggest Scotty (and probably other libraries I'm less familiar with) before Servant in particular, as Servant is a lot to absorb if you're also trying to build fluency in Haskell at the same time. Similarly, I'd advocate for Elmish (disclaimer, it's written by (very talented programmers other than myself at) my company) over Halogen, at least based on the last time I tried Halogen--I found it pretty complex as well. Don't get me wrong, I think Servant and Halogen are both great, just...complex.
-
Building a REST API with Haskell
This is an example of REST API built with Scotty a web framework of Haskell and PostgreSQL a relational database. It's a simple API to manage products.
-
Options for a frontend of demo for a toy app
Not that I'm much of an expert, but if you're talking about a very barebones static single-page-app, then you could very easily get by just using blaze-html to put your elements on the page, and then scotty is a basic web framework you could use to serve up your app.
What are some alternatives?
postgrest - REST API for any Postgres database
lucid - Clear to write, read and edit DSL for writing HTML
graphql-api - Write type-safe GraphQL services in Haskell
reroute - Another Haskell web framework for rapid development
graphql - Haskell GraphQL implementation
json - Haskell JSON library
gc-monitoring-wai - a wai application to show `GHC.Stats.GCStats`
scotty-tls - Run your Scotty apps over TLS
raml - RESTful API Modeling Language (RAML) library for Haskell
scotty-session - Adding session functionality to scotty
simpleconfig
fluid - 🐙 Code-generated, Auto-versioned, & Smart Web APIs