I'm researching BreezeJS for a big upcoming project.
Our goal is a offline first web app.
But here is what I can't fully understand (and would take to much time to test) - Does BreezeJS allow for the backend to be a REST API (built with NodeJS and Express)?
We need this because we don't want to simply sync to a remote DB (in our case Mongo), but use a remote REST API so that we can embed some business logic. Things like workflow triggering on a POST to a particular entity.
Is this possible with BreezeJS? If not what would be a good option?
Thanks in advance
It is certainly possible, simply take the breeze-mongo server implementation and strip out the mongo specific code. This should be fairly straight forward, express and mongo are pretty well separated in the code.
That said, you would lose or have to rewrite much of the server side code that converts an OData query string into a mongo query, but if you are going pure 'REST' you probably don't want that anyway.
You would have to do something similar on the save/POST side, but this is presumably something you are already familiar with.
Related
I'm working on a project that require API that does not exist yet (I thought I would never be in this situation... :D) - so I have decided to build my own.
I'm using MongoDB as a database, Node.js, Express.js as backend framework,and Mongoose as ODM tool.
It's very simple API, all I need is 3 get routes:
GET example/random-item
GET example/all-items
GET example/some-items/:limit/:skip?
And one more thing that I need is a way to post new items to the API:
POST example/add-item
How can I make sure, that I will be the only one, who can access this route?
I want to be te only person that fan maintain the API, users can only GET data, they cannot POST data.
How does it work in a real word, when someome is maintaining some bigger API with more routes and more data?
Kind regards,
Bartek
I'm having a hard time finding information on simple straight forward process. I keep getting forwarded things like the "google cloud engine" and such.
I am attempting to start a new project to expand my knowledge. Previously, I developed a localhost web app which included; working frontend with react, express backend (REST api) and mongo database. I understood the concepts effectively of rest calls, state management and authentications and such.
The new setup is flutter, nodeJS (express), and firebase.
Looking at quick tutorials I have a simple flutter app working with a http post for a user sign up. Makes sense.
Normally in nodeJS, I'd have a route it hits e.g. router.post('/users', function (req, res, next) ... and then I'd have a model scheme to and if everything is correct it would post.
Exploring the relationship with firebase and nodeJS I'm slightly overwhelmed on how this works. I thought it would be something simple as an authentication key (which, btw I have sorted out with firebase-admin) and then proceed on my merry way with my models and routes/services.
Are the models defined within firebase, and my node just confirms the requests and talks through the firebase API? I haven't been able to locate any simple resources for this.
Since you didn't say which product within Firebase you're using (Firebase is a suite of products, not just one thing), I'm going to assume you mean Realtime Database or Cloud Firestore. They are both schemaless NoSQL databases -- they don't impose any structure on the data you put into them. There's no model, there's no validation. That's all stuff you have to do on your own, if you want. Or not, if you want flexibility.
Why should I use graphql if I setup a react frontend and mongo db backend?
And Why should i put graphql server between mongo db and react?
Since you didn't mention what is your alternative API style I will just assume it's REST. GraphQL gives you many features a plain old REST api won't have out of the box.
This is probably the best answer listing advantages and disadvantages of both.
You already have validation(via mongoose schemas), but using GQL you can get:
excellent documentation for your API generated for you
avoid underfetching/overfetching on frontend
ability to batch FE requests easily
you can tap into a very rich ecosystem of GraphQL tooling which only gets better as time passes
easier testing-you can just execute your graphql queries on backend even without sending them over the network saving a little bit of performance overhead
I believe you should use GraphQL for any non trivial API, because it adds ton of typesafety and the price you pay as a developer is very low.
I am trying out React-Starter-Kit for the first time and loving all the cutting edge features baked in (apollo/graphql-client in particular). A crucial part of any app for me is the database, and for that my understanding is the same author provides nodejs-api-starter which sets up a REST interface for accessing Postgres at localhost:5000 and has a graphql webui at localhost:5000/graphl.
That is about as far as I have been able to understand of the setup so far. I have changed the frontend code a little bit so a new Component "Counter" is loaded on the home page. I need to be able to make a new counter, fetch the latest counter, and increment decrement the counter. Write now the component just outputs the 'value' retrieved from the server at 5000.
I do not think I am accessing the 5000 server correctly, do I put the port in this url line somehow?
You can pull the repo down from : https://github.com/Falieson/react-starter-kit-crud-counter-demo
This is my first time setting up a nodejs api server, I am used to using MeteorJS which has pub/sub to MongoDB baked in. I am looking forward to the separation the RSK strategy (which seems more industry standard?) provides.
I've just done setting up the full site with Database from React-Stater-Kit, I'm also a newbie so I understand your frustration.
About this question, you don't need the NodeJS-API-Starter, it has enhanced function ( such as Redis cache ) and it's not suited for newbies. You should look deeper into the RSK, it already has the DB. If you ran the boilerplate and played around, change is you'll see file database.sqlite in your folder, it's the database. Here are the things you should learn:
Use SequelizeJS to connect the NodeJS server with database. Your database can be MySQL/MariaDB, PostgreSQL or SQLite. The connection is easy and there's tool to auto-generate Models from your database
How to create GraphQL's Types and Queries. If your queries need to search through the database, import Sequelize's models and use its functions.
Test your API via GraphQLi
Note: if you want to use MongoDB or other NoSQL, try Mongoose instead of Sequelize.
I went through the Zza sample where BreezeJS is used in combination with an NodeJS (+ MongoDb) backend.
http://www.breezejs.com/samples/zza
In the sample there is no client nor server side validation implemented as we can do with a .Net backend.
Is this simply not possible when using breeze + MongoDb or is it just not present in the sample?
The big difference with the .Net backend is that the meta data are stored client side and not autogenerated from the server. Can we assume that something similar will be possible one day with MongoDb ?
Is Breeze + MEAN production ready or is it still beta material?
Client side validation in Breeze is not dependent on the server. You can define validations directly on the client. There are plenty of examples of this in the documentation for the other non Mongo providers, but the code is the same. In terms of metadata coming from the server, since MongoDB has no schema there is no way to return what would be nonexistent metadata to the client. The only way to do this would be if you were to also use something on the server that more strongly typed the Mongo data ( i.e. something like Mongoose). This has been a request on the Breeze User Voice.
We have not yet created a Mongo example where we automatically validate the data on the server before saving, but this shouldn't be that much of a stretch, but it will be "custom" code.
In terms of being production ready, we are still adding features to the breeze ecosystem, both on the client and the server. However, we do try to limit the number of breaking changes.