graphql-public-schema-filter
parse-server
graphql-public-schema-filter | parse-server | |
---|---|---|
8 | 39 | |
52 | 20,628 | |
- | 0.2% | |
4.2 | 9.4 | |
5 days ago | 4 days ago | |
TypeScript | JavaScript | |
MIT License | Apache License 2.0 |
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.
graphql-public-schema-filter
- Public and Private GQL APIs pointing to same Unified graph?
-
Keeping parts of your GraphQL schema hidden from Introspection
We actually built the following package, @n1ru4l/graphql-public-schema-filter which solves the problem stated within the blog post in a similar way (by filtering an existing schema into a subset of the original schema).
-
Authorization by entities
I am using this technique in one of my projects where we have a public API that is a subset of the internal API. I open sourced the library for doing that: https://github.com/n1ru4l/graphql-public-schema-filter
-
Ideas for implementing admin authentication for only a few mutations?
I built something similar that is "metaframework"-agnostic https://github.com/n1ru4l/graphql-public-schema-filter. Using this method has its benefits and drawbacks. If you simply public and internal part of the schema it can work pretty well. We use it for hiding the internal API from the public customer facing integration API. It is definetly easier than makntaining two seperate GraphQL schemas. However, if you want full inteospection capabilities doing this can be confusing as the introspection query operation result is different based on the authorization header which moght be weird if you are using tools such as code generators, as you now have to do it for two different schemas.
-
When to use multiple endpoints in GraphQL
While building an GraphQL API that powers web applications we introduced a public customer-facing API. Instead of building two separate endpoints we chose to serve a different schema based on the authorization header. Furthermore, requests that do not provide an customer kntegration authorization header are only allowed to execute persisted operations. That way we somehow avoided having multiple HTTP routr endpoints. Instead of building two schemas from scratch and because the public schema is basically a filtered down version of the full graph we decided to filter down the graph using directive annotations on the schema SDL. I open sourced rhe JavaScript library for doing that (which is based upon graphql-tools). The dynamic schema selection based on the authorization header is done with Envelop
-
Any GraphQL issues the community would like to be solved?
graphql-public-schema-filter: This library allows you to filter down you big graphql schema into a smaller subgraph. I have been using this for filtering our big production schema down into a public api schema that our customers use. So they don't have access to all the internal types, that are only for our internal web applications. The great thing about this is that we can just serve the correct schema based on the authorization headers as API users and Web Application tokens differ. If you have one big monolithic GraphQL server this is a great way of doing this and we are quite happy with it.
-
Introducing Envelop - The GraphQL Plugin System
Public schema filter - for creating a simple GraphQL schema that can be used for public APIs based on existing GraphQL schema.
- I built a small library for filtering a GraphQL schema graph into a subgraph
parse-server
-
The 2024 Web Hosting Report
Backend as a Service (BaaS) goes back to early 2010’s with companies like Parse and Firebase. These products integrated everything a backend provides to a webapp in a single, integrated package that makes it easier to get started and enables you to offload some of the devops maintenance work to someone else.
- Placemark is going open source and shutting down
- Thoughts on Parse Platform / Server
-
Tools for scanning commits?
Prototype Pollution Fix
-
How to set up a Parse Server backend with Typescript
Parse Server is a great way to quickly spin up a backend for your project. Parse is a Node based utility that sits on top of ExpressJS.
-
A Guide On Appwrite
Parse
- [SERIOS] Solutie backend + DB pentru o aplicatie web
-
Free online DB for production app
You can try https://parseplatform.org/, it is self-hosted if you need. And also there are a number of cloud services with compatible API, like https://www.back4app.com/ It has dart-friendly generated API client, much simpler than firebase and is built on top of postgresql and mongodb.
-
Backend (auth/payment) options for Flutter app and web.
Parse - https://parseplatform.org/
-
Supabase Series B
Not to crash the party or anything. Supabase is great and all but in terms of feature completeness and getting actual products built, it doesn't come close to Parse[0].
Same with Appwrite. Both of these are very popular but they either lack essential features or have them behind a subscription wall. For example, the OSS version of Supabase (last I checked) doesn't include the edge functions which are really important for easily computing stuff on the server side. Parse on the other hand is 100% open source and has a huge feature set. It's older than all of these lo-code tools and actually helps solve the issues one comes across when using such tools.
Another thing is extending these tools which is a pain. For example, Parse supports multiple databases by default (postgres & MongoDB) and the ability to write a custom adapter if you need something else. Similarly, if you at any point need to go 100% custom it also makes that possible so you are never locked in. These tools however don't have that level of low-level control and are general all or nothing kind of tools best for small-to-medium sized problems which don't have a lot of room to grow.
But both of these (Appwrite & Supabase) are super markety. Appwrite is all over the place with their ads, Supabase got a huge trend when it launched etc. Parse on the other hand is not too good at marketing their product being fully community run which is one reason not many know of it. Another is their not-so-fancy docs.
I have no stake in any of these products: just my conclusion after having tried all of these.
[0] https://parseplatform.org/
What are some alternatives?
nestjs-graphql - GraphQL (TypeScript) module for Nest framework (node.js) 🍷
Appwrite - Your backend, minus the hassle.
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
supabase - The open source Firebase alternative.
envelop - Envelop is a lightweight library allowing developers to easily develop, share, collaborate and extend their GraphQL execution layer. Envelop is the missing GraphQL plugin system.
graphql-jit - GraphQL execution using a JIT compiler
ObjectBox Java (Kotlin, Android) - Java and Android Database - fast and lightweight without any ORM
graphql-helix - A highly evolved GraphQL HTTP Server 🧬
MongoDB - The MongoDB Database
galactagraph-boilerplate - 🚀 The best&fastest way to create and manage your World-Dominating Federated GraphQL API
Vapor - 💧 A server-side Swift HTTP web framework.