I create app using C# RestApi as backend and React as frontend.
I would like to ask you whether you inventory the use of backend models in the front.
In VS (C#) I can use F12 to detect reference. I have no idea how to do this in REST where JS does not need to recreate the class.
The backend developer may not be able to access the frontend code. Do you have any practice on how to record the use of the model on the REST/React so that the developer can quickly see if he can change the appearance of the backend model class.
Well, there is no strict connection between models defined in the backend and frontend in this case.
The connection is just made when a client calls an endpoint on a server.
The most common practice is to use DTO as returned data(Data Transfer Object) with all properties which you need on the front, not models.
So on the frontend, you create the same class as DTO on the backend and you just use some libs to support the process of mapping like the automapper.
In this case detection of using models needs to be found by URL.
Related
I have a Single-Page application using Entity Framework on the backend and Breeze.js on the client. I'm also using the breeze .Net EF classes. In order for the breeze client to create breeze entities on the client, it calls a controller method named "MetaData". This method returns a collection of all the entities in the database, even those that may not be used on the client.
Even though there is no coding logic in the metadata, it does contain a complete schema of the database. Some of these entities are used for security and business logic, and I wish to not have this entire structure open to the world.
Is there a way to exclude entities (not just individual properties) from the breezejs metadata collection?
Thanks
The easy way is to create a DbContext that has only those classes and relationships that you want to expose. Use the fluent interface to shrink it down and cauterize relationships that you don't want.
Then create an instance of an EfContextProvider based on this limited DbContext.
You can use this cut-down DbContext exclusively for metadata generation if you wish. You can switch to something more robust (wrapped in a different EfContextProvider) if you must.
See the documentation chapter "EF as a Design Tool".
My Goal:
Create a private messaging platform using Sails.js with the simplest code possible
Assumptions of Best Practices:
Use Sails.js Webockets for realtime notifications
Use Sails.js PubSub for DB use with websockets
Use Sails.js .watch() to get messages
My Questions:
Can I have a socket watch only certain new models (e.g. find where userid matches sender or recipient id) OR do I need to set up rooms? Selective watching seems much easier, but the documentation doesn't seem to support it.
If any of my above assumptions or questions are not the best way to realize my goal, then what is the simplest way to implement private messaging using Sails?
What I've Tried:
Subscribing and watching a socket
Reading the Sails.js documentation
Looking at the sailsChat example (uses rooms)
Searching StackOverflow and Google for sails chat examples
The simplest way I guess it is using the socket.io implemented in sails, if I remember correctly it is simply called socket.
All controllers can be called with socket.io (client side) IIRC.
The approach that I took is to create a model called messages, and then simply create few endpoints for the messages. If you want to use the models (pub/sub) it is possible to subscribe just to the ones you want. you can subscribe every single user to just a single Model, even if you have plenty of them.
What I used to do is do it manually, when I receive one message, i would emit it to the right client straight away. But if you want to write less code probably you simply have to subscribe the users to your model Model.subscribe()( http://sailsjs.org/documentation/reference/web-sockets/resourceful-pub-sub/subscribe )
so when a message is added to the Database then you can send it to whoever you need to.
Here's another example of a chat built on top of sails.js: https://github.com/asm-products/boxychat-old
I'm trying to find a way to lower the possibilities for mistake when working with three tiers of information. Let me try to explain.
I'm building a web app with:
Node.js
mongodb
react (with server side rendering)
flux (alt.js)
browserify
The data flows can be one of these two:
User ask for a page -> data helper getting the proper data from the db -> passing to alt.js bootstrap to fill all the stores -> asking react to build the app (renderToString) and components rendering the view -> retuning to the client
User updates something -> flux action is sent (calling server with ajax) -> data helper preparing the data to be saved in the db -> saving and returning the result to the client -> store updates the state -> react component updates his view
There are three places that need to know the data structure:
The data helper in the server that export the proper data from the data structure and send to the mongodb or gets the data from the db and build the data structure
The flux store that updates his state after user action
The component that render the view from the state
This means that if I want to change the data structure (even if to change the name of one of the properties) I will have to change it in three places which can be very risky and prone for mistakes.
Is there a way to achieve data coupling in JS?
I have been looking into this somewhat, but for a client-side application only. We considered going with an immutable datastructure solution, of which there are several.
In the end we instead went with a message bus solution, based on PubSubJS to message changed state to all parts of the app. We coupled this with a helper function responsible for updating the state of the datastructure, so that all updates are controlled by that function.
I think the feature you wanted is syntax check, which is one of compiler features. And javascript is not a compile language. So my suggestion is to change a language. For me, I've worked with Typescript for a long time, it works fine to me. It is a compile language, and javascript is what it compile to. I think it can fits you needs after you defined your interface.
I have an app I am designing using node/mongo/angular, what I am not getting is how is the best way to get my data from mongo into my pages? I can use node, and thru my routes send back data from mongo with my template(hogan in this case), and bind using mustachejs. That works fine for most things. I have one screen that has a decent amount of drop down lists, to bind them for an edit scenario now seems a challenge. I would like to get them bound to an angular model and go about it that way. Is it better to get the data thru the route in node, then use something like ng-init and get it into angular? Or would I be better off not getting the data thru the route in node, and then using angular to perform a "get" request and bind that way?
From the documentation of ng-init, more precisely from the red warning alert at the top of the page...:
The only appropriate use of ngInit is for aliasing special properties of ngRepeat, as seen in the demo below. Besides this case, you should use controllers rather than ngInit to initialize values on a scope.
So no, do not use ng-init. While that can be a good strategy for lazy migrations from regular applications to single page applications, it's a bad idea from an architectural point of view.
Most importantly, you lose two things:
An API. The benefit of SPAs is that you have an API and that you're constantly developing and maintaining it, even before it has external users
A clean separation of concerns. Views are strictly limited to presentation, can be cached by the client and all data is transferred through JSON API endpoints.
I would say that the best way to get data from Mongo into your page, is as mnemosyn said, using an API.
Basicly, you can have your API route, f.ex '/api/data' configured and then it can be used by a angular service, (which can use ngResource to make things easier). Any controller that wishes to access this data can use the angular service to get it, do some stuff with it, and then update it using the same angular service.
Using the Backbone Model and Collection utilities to interact with REST endpoints that return logical entities in your backend system makes sense. For example, endpoints like the following very logically map to models and collections:
GET /posts/:id > Model
GET /posts > Collection
PUT /posts/:id > Model
But what about endpoints that don't really map to a logical entity in your model? For example:
POST /user/login > ?
POST /user/validate-token > ?
It doesn't seem to make sense to force Backbone Models/Collection to work with endpoints like this. Writing some sort of service class using $.ajax or similar seems to be more appropriate. Trouble is we've spent quite a lot of time extending Backbone.sync to respond to particular error codes globally and don't want to duplicate that functionality in a service class too.
How are people interacting with REST endpoints that don't map to models and collections in their Backbone apps?
Going to go ahead and answer my own question here. "mu is too short" got me on the right track in the comments above.
Since Backbone uses $.ajax to handle all its HTTP requests by default you can leverage $.ajaxSetup() and $(document).ajaxError() etc. to handle any app-wide AJAX setup and error responses. Then you're free to write your HTTP service classes using $.ajax too and leverage the same setup for both layers of server communication.