Our great sponsors
opaleye | fquery | |
---|---|---|
9 | 5 | |
594 | 10 | |
- | - | |
8.5 | 0.0 | |
11 days ago | over 2 years ago | |
Haskell | Python | |
BSD 3-clause "New" or "Revised" License | MIT 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.
opaleye
-
What's your favorite Database EDSL/library in Haskell?
If you ever have any questions about Opaleye I'm happy to help. Feel free to open an issue to ask about anything any time.
-
Persistent vs. beam for production database
Sounds like Opaleye isn't on your list of choices, but if it is then feel free to ask me any questions, any time by filing an issue (I'm the Opaleye maintainer).
-
How to build a large-scale haskell backend for a photo sharing app (some questions)
Opaleye is Posgres-only, and Postgres does such a good job of optimizing queries that performance issues basically don't arise. I have a long-standing invitation to improve Opaleye's query generation as soon as anyone can produce a repeatable example of a poorly-performing query. In Opaleye's eight years, no one ever has. There's a thread where two reports have come close, but it's still not clear that that's simply due to using a six year old version of Postgres.
- What are things that the Haskell scene lacks the most?
-
Out of memory when building product-profunctors
Nice! Well done. If you have any more questions about product-profunctors or Opaleye then please let me know. It's best to ask by [opening an issue](https://github.com/tomjaguarpaw/haskell-opaleye/issues/new).
- Embedded Pattern Matching
- How to simply do opaleye field type conversion
-
Against SQL
The only way out that I can see is to design embedded domain specific languages (EDSLs) that inherit the expressiveness, composability and type safety from the host language. That's what Opaleye and Rel8 (Postgres EDSLs for Haskell do. Haskell is particularly good for this. The query language can be just a monad and therefore users can carry all of their knowledge of monadic programming to writing database queries.
This approach doesn't resolve all of the author's complaints but it does solve many.
Disclaimer: I'm the author of Opaleye. Rel8 is built on Opaleye. Other relational query EDSLs are available.
[1] https://github.com/tomjaguarpaw/haskell-opaleye/
-
Combining Deep and Shallow Embedding of Domain-Specific Languages
For an example of how this plays out in practice observe Opaleye's MaybeFields (generously contributed by Shane and /u/ocharles at Circuithub). The definition is essentially identical to Optional from the paper. Instead of a specialised typeclass Inhabited we use the ProductProfunctor NullSpec (which happens to conjure up an SQL NULL, but it could be any other witness).
fquery
-
Solving the double (quintuple) declaration Problem in GraphQL Applications
Similar benefits without codegen (based on decorator magic) for a python based stack:
https://github.com/adsharma/fquery
* Use dataclasses for both database schema and the user facing operations
- Cut Out the Middle Tier: Generating JSON Directly from Postgres
- Against SQL
- Django for Startup Founders: A better software architecture for SaaS startups
-
SwiftGraphQL – A GraphQL client that lets you forget about GraphQL
Re: Conways law at Facebook
I was at Facebook when GraphQL was invented, maintaining a backend storage service where a core assumption was that storage should be reorganized based on access patterns and that predicates should be pushed down to storage where they can be executed more efficiently.
GraphQL was hard to push predicates down, because you don't know which of the edges were written in PHP.
My response was fquery[1], which is like what's being discussed here but with python as the source language instead of swift and amenable to preserving the largest possible query structure for backend optimizers, including SQL optimizers.
It has some early demos converting a GraphQL/fquery into SQL where possible. It should be possible to add enough metadata to fquery to identify if an edge is non-trivial (calls into another microservice) or trivial (can be optimized to a storage backend or SQL).
[1] https://github.com/adsharma/fquery
What are some alternatives?
esqueleto - Bare bones, type-safe EDSL for SQL queries on persistent backends.
django-ninja - 💨 Fast, Async-ready, Openapi, type hints based framework for building APIs
mywatch
rel8 - Hey! Hey! Can u rel8?
HDBC - Haskell Database Connectivity
prosto - Prosto is a data processing toolkit radically changing how data is processed by heavily relying on functions and operations with functions - an alternative to map-reduce and join-groupby
database-migrate - database-migrate haskell library to assist with migration for *-simple sql backends.
DjangoChannelsGraphqlWs - Django Channels based WebSocket GraphQL server with Graphene-like subscriptions
HongoDB - A Simple Key Value Store
django_for_startups - Code for the book Django for Startups
squeal-postgresql - Squeal, a deep embedding of SQL in Haskell
jrutil