Excuse my ignorance in this area: most of my programming has been in optimization and research. I am very new to GraphQL and client-server programming.
My organization is working on an automated scheduler in Python 3.9 for scheduling observations for a large-scale telescope.
We are relying on many different services to all communicate via GraphQL. At the moment, I am trying to implement a GraphQL server that can be queried or accept subscriptions to disseminate when a new schedule for the night is created (for any number of reasons such as changing weather conditions, instrument faults, modifications to observations). Eventually, we will need to allow mutations (e.g. to the priority of observations, or to fix an observation at a given time).
I am looking at both Strawberry and Graphene as my possible options, but what is unclear to me is if I require them to be combined with a web framework service like Django or Flask to achieve the functionality that I need.
I see that Strawberry has a built-in (possibly only debug) server, but it also discusses integration with Django, Flask, and others, and I am not certain if I need to go to that level. I have been working through examples and completed a JavaScript course using Apollo Server / Client, but I'm not sure how these compare to Python GraphQL server implementations.
I apologize for my lack of knowledge: I am trying to keep the project as simple as possible for now, and having played around with Graphene and Django, I'm not sure if I'm overcomplicating things of if this approach is necessary.
Statements like "Graphene is fully featured with integrations for the most popular web frameworks and ORMs" lead me to believe a web framework is required, but again, I am not sure and feel very out of my depth since in this area is virtually nonexistent.
I'm the maintainer of Strawberry GraphQL 😊
For both Strawberry and Graphene you'd need framework like Django or Flask.
Strawberry has support for Subscriptions when using an ASGI framework like Starlette or FastAPI, there's some example here: https://strawberry.rocks/docs/general/subscriptions#subscriptions
We also have an almost-done PR that adds support for subscriptions using django: https://github.com/strawberry-graphql/strawberry/pull/1407
Related
I am evaluating Sails.js as potentially the most closely aligned alternative for a migration of about four years of development on the Wakanda JS full stack platform. I would appreciate perspectives from the Sails.js community based on the following overview:
AS-IS: WakandaDB, Node.js / SSJS / Node Workers / Shared Workers; Client side: Angular 5 for Web and for Ionic/Cordova hybrid mobile apps.
Wakanda DB and Wakanda API and dataclass / dataclass method architecture and all of its off the shelf capabilities will no longer be in play.
It seems that Sails.js is the most closely aligned to my current technology stack. Does the community agree with this? I understand the community is pretty large, but I do not see evidence of this in terms of books on Amazon (as compared to the Meteor platform for example).
Appreciate perspectives and any references to migration related guides/references.
Kirk
I'm using sails.js professionnaly for four years now.
I worked with version V0.12 and now V1.0.
I've never heard of the Framework Wakanda so i can't tell you if the technology stack match.
All i can say is Sails.JS have strenghs and weaknesses.
I will just give you the cons so you can see if this is a no go for you.
The community is not the most active, a lots of good stuff developed for v0.12 isn't ready for v1.0 after years (i'm thinking of sails-auth and sails-permissions who provide good ACL structure).
He could be to big for small projects but i don't think it's a problem for your needs.
He works great with MongoDB but not that much with other DB system (even if community developed adapters for other DB as postgresql).
And for me the biggest weakness of this framework is his ORM.
This one will play with your nerves, you will have to rewrite some parts like the one who create the criteria of the query from express req and set default limit to your query even if you don't ask it.
I you don't use mongo, don't use the migration script provide by the adapter and build your own with db-migrate.
So i will recommend Sails JS for project with complex API but simple DB structure.
Hope this will help you in your choice ;)
I am working on an app that would greatly benefit from Arangos' multi-model capabilities. Considering the app needs for the back-end, I have concluded that most, if not all, of it could be served through a REST API as to aid cleaner design for future development and integration with others. The API would then be consumed by several web and mobile front-end frameworks to handle the rest of the logic. The project will be developed with Javascript for the whole stack, using the NodeJS ecosystem.
.
The question itself:
Should and could one use arangodb + foxx to create the complete back-end stack for serving a REST API, thus avoiding another layer/component in the stack? e.g. express/hapi/loopback etc.
.
Major back-end requirements:
Authentication with roles
Sessions
Encryption
Complex querying (root of my initial thought, as to avoid multiple hops between DB and back-end)
Entry parsing, validation and sanitization
Scheduled tasks
.
Mainly looking for:
Known design advantages
Known design limitations
"Hidden" bottlenecks
Other possible future regrets
.
Side question (that might answer some of the above): Could Foxx utilise some of the node middleware available via npm?
Thanks in advance for your time!
You can use ArangoDB Foxx as the sole backend of your application, however it is important to keep the limitations of Foxx (compared to a general purpose JS environment like Node.js) in mind when doing this.
You mention encryption. While ArangoDB does support some cryptography (e.g. HMAC signing and PBKDF2 key derivation for passwords) the support is not as exhaustive and extensible as in Node.js. Also when using computationally expensive cryptography this will affect the performance of the database (because unlike Node.js Foxx is strictly synchronous and thus all operations should be considered blocking).
ArangoDB does not support role-based authentication out of the box but it is perfectly reasonable to implement it within ArangoDB using Foxx (just like you would implement it in Node.js, except you don't need to leave the database).
For sessions there are generally two possible approaches: you can either use a collection with session documents (using ArangoDB as your session backend) or you can keep your services stateless by using signed tokens (Foxx comes with JWT support out of the box).
Complex/stored queries and input validation (using the joi schema library originally written for hapi) are actually some of the main use cases of Foxx so those shouldn't be any problem whatsoever.
Foxx comes with its own mechanism for queueing tasks, which can also be scheduled ahead or recur periodically. However depending on your requirements an external job or message queue may be a better fit. The good thing is you can get started with the built-in job queue right away and still move on to a dedicated solution if the need arises during development.
As for middleware and NPM packages: Foxx is not fully compatible with Node.js code. While we provide a lot of compatibility code and try to keep the core modules compatible where possible, a big difference is that Node.js is generally used to perform asynchronous operations while in ArangoDB all operations are synchronous.
If you have Node.js modules that don't use crypto, file or network I/O and don't use asynchronous APIs (e.g. setTimeout, promises) they may be compatible with Foxx. A lot of utility libraries like lodash work with no problems at all. Even if you find that a module doesn't work it may be possible to write an adapter for it like we have done with mocha (integrated into Foxx) and GraphQL (via the graphql-sync package on NPM).
In my experience it is a good approach to put your Foxx service behind a thin layer of Node.js (e.g. a simple express application that mostly just proxies to your Foxx API) and/or to delegate some parts of your backend to standalone Node.js microservices (e.g. integration with non-HTTP services like e-mail or LDAP) which can be integrated in Foxx via HTTP.
One more thing: while a lot of existing express middleware likely isn't compatible with Foxx because of Node-specific dependencies and async logic, ArangoDB 3 will bring a new version of Foxx with support for middleware using a functionally express-compatible API.
I'm just starting to port my sails application to a FOXX application so I can answer some of your questions.
Role based authorization in ArangoDB is probably at too high a level than you want. In our case, we use an external service to authorize various web and service based applications at a very fine-grained level (much lower than a vertex or an edge). My feeling is that Authorization at that level will require you to write it yourself in javascript. If it's just CRUD on a per collection basis, then it shouldn't require much effort.
For authorization and sessions, I would look at the FOXX example found at: FOXX authorization-session example
It's not clear what you're asking about encryption. If you're talking about SSL connections, then that is natively supported (see arangodb end-points). As for internal encryption, there is a javascript crypto module ArangoDb crypto
Entry validation, etc. is supported by the javascript joi package.
Complex querying... Absolutely and getting even better in ArangoDB version 3.x. Traversals can be chained (go down using one edge collection, then up using another).
You're right on the ball when thinking about efficiency. This is the main reason we're going from sails to FOXX. In our case, we filter query results based on permissions from our external service. This means that we can't use ArangoDB native skip and limit support if these attributes are specified by the client. In sails, we have to bring back results in chunks and collect until we hit the appropriate skip and limit values. By moving to FOXX, we save a lot of network and other resources. We tested this by having sails forward the request to our prototype FOXX implementation. This scaled much better than the sails post-processing setup.
You can use NPM modules with restrictions. See Javascript Modules
I am trying to build a social networking site/app.After some research the conclusion I reached was to use a Graph Database. Neo4j is the most mature and used Graph database
Now I need to provide authentication and authorization to the database and I want to authenticate using OAuth so as to authenticate via facebook/google.
The problem I am facing is that I want to use the REST API which provides data on the basis of a person's authorization but I am not able to decide which framework/tool to use. I want this framework/tool to be fast,reliable and scalable.
The choice of a framework is quite a matter of taste on a person basis.
For Python you have Django and Spring for Java, both offers OAuth.
Now, this has nothing to do with your database, a user will never be connected to the database.
Also, a framework will not make your development life easier in the first 12 months, learning a framework takes time, and security is a hot topic and you need to learn all the little tricks of that specific framework.
In the meantime, you'll have to learn Neo4j and his integration with your framework.
I want this framework/tool to be fast,reliable and scalable
I think, depending of your development skills, that attending a fast, reliable and scalable application state with a framework you need to learn and a database you need to learn, this should take approximately two years.
I'm, going to write a web app, which should be CRUD accessible from both, the web and native mobile device apps. For the latter i'm definitely committed to a REST API. Is it possible to realize that with Meteor.com ? Would it be an option to use Meteor for just the web and a second REST interface to directly talk to the mongo? Since the meteor client listens for changes in the mongodb this should not cause conflicts, does it?
As of 2015, look at Gadi's answer for the Meteorpedia entry on REST APIs, and at krose's answer comparing REST API packages. Discussion for folding REST APIs into core is on Hackpad. This question is a duplicate of How to expose a RESTful service with Meteor, which has much better answers. -- Dan Dascalescu
Old answer (2012) below.
For adding RESTful methods on top of your data, look into the Collection API written for Meteor:
https://github.com/crazytoad/meteor-collectionapi
As for authentication for accessing the database, take a look at this project:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
Both are definitely infantile in development, but you can create a RESTful API and integrate it with a mobile native client pretty easily.
There are a lot of duplicates of this question. I did a full write-on on this in Meteorpedia which I believe covers all issues:
http://www.meteorpedia.com/read/REST_API
The post reviews all 6 options for creating REST interfaces, from highest level (e.g. smart packages that handle everything for you) to lowest level (e.g. writing your own connectHandler).
Additionally the post covers when using a REST interface is the right or wrong thing to do in Meteor, references Meteor REST testing tools, and explains common pitfalls like CORS security issues.
If you are planning to develop a production application, then Meteor is not an option right now. Its under constant change, and there are still many common features it has to support before its ready to use, which will be quite some time.
For your Question, Somebody has already asked and answered the question about support for file uploading in meteor(also contains HTTP handing related information).
How would one handle a file upload with Meteor?
I would like to create a module for the Pinboard API.
Though very similar to the old Delicious API, there are enough changes that I would like to re-implement to specifically work for Pinboard.
The Net::Delicious module was build initially in 2002 and I see that many of the newer REST best Modules are implemented in a new way. Net::Twitter, WebService::Dropbox and WWW::Vimeo::Simple seem to have different methodologies on how to implement their respective REST API.
Net::Twitter is very complex and heavy implementation in my opion. WebService::Dropbox is extremely light as is the API it implements. WWW::Vimeo::Simple seems to be between the two in terms of complexity.
I also spent some time looking at REST::Client but it probably would not be useful if you want to implement more that one or two methods.
What are the best practices for implementing a complete REST webservice? and also to test the responses without being able to connect to the service.
What you want is Net::HTTP::Spore. It's a moosy framework for REST clients in modern Perl. See also these slides