Angular2 Consuming rest api with base url or not - javascript

I have more of a style question. So I have my services classes with my http calls. What would be best practice in Angular
http.get("/api/some-stuff")
or
http.get("${api.url}"/some-stuff
What would be the better approach? I noticed with the first one, I need some sort of proxy and url rewrite on my web server after I build the project.
For the second approach I need some sort of env deployment. But as said. What is best practice here?

Yes, this is just opinion question and i would like to say, that from my point of view the best practice would be to have in memory service wich will handle your rest api uri and:
http.get(urlResolver.getBase() + urlResolver.getYourEntryPoint())

Related

Best practice to structure service/factory in angularjs

I was studying angularJs last week and there's something I'm not sure about.
For example, in a project that has some CRUDs of Student, Teacher and Supplier. Is it a good practice split the services/factory for each models (student, teacher and supplier)? or Is it better use one generic service/factory for the same models, like "write once, and run in everywhere"?. I think the second option maybe works for big projects, because you can write less code, but I have no idea about the maintenance.
Obs: The service/factory reffered above has functions with $http to list, add, edit and delete a registry from database.
And Is there any detailed style guide with best pratices for AngularJs?
Thanks in advance!
If you can manage the API endpoints at the back-end side you can create your services based on $resource. All you need (at the front-end side) is to set the endpoint URL. By call of $resource predefined methods like get, save, delete and etc. (you can add your custom methods as well) the $resource will submit HTTP requests with particular HTTP methods (GET, PUT, POST, DELETE) to the defined API endpoint.
If you want to stick to angularJS I would advise you to check this angularjs style guide from Todd Motto, it's most likely best one online:
https://github.com/toddmotto/angularjs-styleguide
Really has best practices using component based architecture. You will improve your code drastically and even merging to Angular would be easier.

GraphQL and dataLoader on separate applications/servers

I plan to implement a GraphQL API in .NET on IIS and dataLoader API as a Node.js app server. GraphQL will interface to dataLoader to SQL Server.
All applications will be on a single physical server for now, but may possibly be separated in the future if scalability requires.
My reasons for this:
Existing code depends on IIS/COM/DCOM/ActiveX/.NET/ASP/ASPX
Simpler to implement and reason
Access control (web server doesn't need to see dataLoader code and ACLs can be implemented in dataLoader)
Makes it easier if I get the chance to interface with a different db (redis, mongodb, etc)
I can gradually slice and port parts of the code to allow easier code sharing (with separate Linux servers)
(I like) Node.js open to exploration, but cannot opt-in yet
First off, does this make sense or am I asking for trouble?
Would it make sense to use a binary serialization format between GraphQL and dataLoader? Or perhaps just a simple web service would be simpler?
Am I risking performance problems from more round-tripping? (Question too open-ended? Intuitively it seems like this would scale better eventually)
Is there a need for explicit authentication between GraphQL and dataLoader? Or can I just send session data (with username) through as-is and just let dataLoader trust the username given as context? Maybe pass a token? Are JWT tokens useful here?
GraphQL-dotnet has matured a bit since then and is looking pretty good.
I've since looked into solutions like AWS's API Gateway GraphQL support, and some Azure Functions solutions that support GraphQL.
Some of the techniques and design choices involved in these things were helpful here and there. But due to practical reasons, this never really came to fruition and most of these concerns never became relevant.

Good solution to work with rest-api like SPA with redux?

I'm trying to implement admin-site for commenting-system. I have REST-API with JSON. I don't want do isomorphic application. I just want feel in Single Page manner. I see there is already has some solutions:
1) Create ajax factory and send request to api methods with XmlHttpRequest, during dispatch action and handling this by hands.
2) Redux-api or redux-rest.
3) Method that used in redux real-world example.
For my job i need's stable solution. I think to choose redux-api. But i don't know which disadvantages can be in each variant.
Maybe anyone has the same problem?
There's no definitive answer to this; however I am using a variant of redux-api-middleware which allows me to keep my action creators stateless and free of side effects.
redux-api and redux-rest both look valid; if somewhat 'magic' based on the amount of configuration / convention they enforce on your app.

Best way for a Node.js application to interact with an external program

I am a beginner to web development - I am building a website that requires some entries from the user, does some complicated mathematical processing on those entries, and returns the result to the client. I was thinking of implementing the mathematical stuff in another separate application which is better suited for such work (like in Java or C++ where there are good math libraries and the implementation would be more robust and faster). I was wondering what is the best way to do this, architecture-wise.
The "dummy" approach would be spawning a process from the Node.js application and waiting on its output from stdout, parsing it (probably in JSON) and then processing it before sending the result to the client. I have trouble believing that this is the best way to do this (it seems too error-prone, no proper error handling, dependent on the output, and just plain bad practice). A slightly better approach would be to have the Java or C++ application listening on a specific port and waiting for requests from the Node.js application. However this requires more thinking in terms of load-balancing (how would it scale with the number of requests?). Finally, the last approach I found online was to use a queuing system such as RabbitMQ as a way to communicate between the Node.js application and the Java application.
Typically (in a "traditional" software), implementing a separate library that holds all the math magic to which we can make calls would be a good way to go.
What is the best approach to achieve this with a Node.js/web application? There must be good practices/models/architectures/designs for such a problem. Thanks!
The best approach I can think of is writing a native nodejs module, you can use C++ and any library you have to write the code and export some APIs to be called from node's javascript.
This also allows you to package your native application as a module for nodejs, which can then be distributed and compiled/installed with npm.
Here's the official tutorial from node's website.
It isn't the easiest approach, but certainly the more elegant and mantainable one.
IF your problem can be structured in a stateless way -- i.e. you send a request out with the data and the associated task, and then later receive the result as a response, I would probably create one angular app for the front end, and multiple node servers for the back end (IF you needed to handle many requests simultaneously).
As pointed out in the first answer below, you can put whatever parts of the problem that you want to into native code, BUT what might be much easier is to use sockets to connect to a server to do the computation, in any language, etc... In one project I use a socket.service to handle all the communication back and forth to the servers. (The angular-fullstack generator in the next paragraph has such a skeleton socket.service piece.)
In terms of the frontend in combination with a node backend, The Yeoman generator (http://yeoman.io/generators/) for creating MEAN stack applications, using MongoDB, Express, AngularJS, and Node - lets you quickly set up a project following best practices. And the angular-fullstack generator will give you a framework that is light years ahead in so many ways. You can use yeoman to generate a sample application frontend (angular, express) and backend (NodeJs, MongoDB) with support for sockets, etc...
This too is not very simple, but in the end, with a few months of work, you would have a structured problem and solution that you would never outgrow. When I first wanted to work into this space, that was the path I took. And in truth the front-end was/is the harder part and the backend, connected with sockets, http, or whatever has gotten to be much simpler. In terms of servers, AWS, or even just nginx on Linux through DigitalOcean or many others is inexpensive and flexible.
I hope this helps.

Angular Service Factory Factory

My understanding of angular services is that they are used to access external data sources amongst other things.
So let's assume I have a service to access feeds, that deals with the ATOM parsing, etc.
Now, let's assume a controller needs to access several feeds.
Is there a way for me to parameterize services as they are instantiated? Since services are singletons, do I need a service factory factory? Should I be using the same service and passing details of the particular feed each time? What if I need to make more than one calls to the same feed and would like a dedicated object to speak with? (think websockets instead of feeds).
Is there another approach altogether that would work for this?
Is there a way for me to parameterize services as they are instantiated?
Not really. You can inject things into a service – e.g., another service – but I don't think that will help you here.
Since services are singletons, do I need a service factory factory?
I don't know how you would write that, but again, I don't think it would help here.
Should I be using the same service and passing details of the particular feed each time?
Well, as I asked in the comments, if you are dealing with a fixed set of feeds, I would hard-code them into the service (or maybe have the service fetch them from a configuration file on the server), and allow the controller to ask for them by name or some ID.
If you need something more dynamic, then I think you'd have to pass in the feed details to the service.
In either case, I think one "atomFeed" service would be sufficient.
What if I need to make more than one call to the same feed and would like a dedicated object to speak with?
I would probably still use one service. I'm not sure what the issue is here though.

Categories