I am building a api on loopback. I was curious if loopback is a Baas or a mBaas framework. What I mean is will I face any problem if I would use it for my website builded in angularjs?
Will my api handle about 300req/s for all my requests?
Loopback is mostly a generalized Baas framework. One of it's use cases is web applications that uses angularjs. I actually do use loopback as a backend for a Angular.js webapp.
Yes mostly, but that depends on your business logic, your servers, databases, server load and a lot of other factors.
Loopback builds an http rest API that can get connected to databases or other rest or soap backends. It also has a few clients libraries, which includes plugin for angular resource. You can also write your own connectors or client library.
Related
We have many web apps deployed in tomcat container. All these applications, make REST API calls to a couple of external services. What we want is all these rest API calls (across these web apps) to be going via single Hystrix gateway so we can build resiliency into the system. Any idea how to do this? If these independent web apps package hystrix in their own war then there will be multiple hystrix instances created? How to have a single instance of Hystrix per JVM which should deal with multiple web apps ?
Thanks,
Sidd
You need a gateway that will serve as a reverse proxy to dispatch incoming requests to the different services. This gateway can implement hystrix commands in order make the calls to the different external services.
Look at Zuul made by Netflix it's the most popular choice in terms of gateways. Hystrix is already in place and wraps the different external calls. You can also use spring cloud Netflix which includes an embedded Zuul proxy, here's an example: https://spring.io/guides/gs/routing-and-filtering/
I have previously used
#app.route('/mypage/<int:myvariable>/')
to create rules for what should happen when users land on different urls on my website. I have done this on local machines that have been running on my own virtual servers.
Now I am learning to publish my first web app to Google App Engine. I have heard that I should be using Google Cloud Endpoints instead of the route decorator.
#endpoints...
I've read a few articles about endpoints and some of the benefits of endpoints that they list are:
Endpoints makes it easier to create a web backend for web clients and mobile clients
Endpoints free you from having to write wrappers to handle communication with App Engine
Even if I have read this I can't wrap my head around what this means. I don't understand it. Can you explain in non-technical terms with examples what the advantages of using #endpoints is compared to alternatives? The alternative that I am familiar with is #app.route.
Google Cloud Endpoints can be thought of as a subset of #app.route. They are intended to solve the API backend problem for mobile and javascript clients. They are not intended to serve web pages and other hypermedia. You can use the normal routing methods of your framework of choice to create a web service for your application but Google Cloud Endpoints takes care of a lot of boilerplate for you.
There are a lot of limitations with Google Cloud Endpointsso be sure to familiarize yourself with them before committing. For one, you cannot host Google Cloud Endpoints on a custom domain name. They are only accessible via <app_id>.appspot.com/_ah/api/*
Endpoints makes it easier to create a web backend for web clients and
mobile clients
What this means is that you can create one backend and then iOS, Android and Web-apps (via Javascript for example), can execute your API methods with specific client generated libraries.
This is convenient if you are building a backend that you want to be easily accessed via smartphones or through a web browser.
Endpoints free you from having to write wrappers to handle
communication with App Engine
With Endpoints you can generate client libraries (e.g. Android, iOS, Javascript) that you can then execute your API methods. You don't have to worry about writing a bunch of additional code to do that.
My Opinion:
I have never used Cloud Endpoints to make a web-app but it is very convenient if you are making a mobile app for iOS and Android because you can access your backend with both platforms.
One reason you might want to use Cloud Endpoints for a web-app instead of something else is because of Datastore. Datastore is the way Cloud Endpoints stores data. It is a NoSQL storage method which is kinda tricky to wrap your head around at first if you come from a relational database background, but once you get it, it makes a lot of sense.
Our team want to choose a technical architecture for our future ERP web application. We have fixed the choice for the back-end layer, actually we'll use Spring Data JPA/Hibernate and CXF web service to develop the service layer.
Right now we're a little confused about the font-end framework to use so as to develop the client layer. Can anyone give me his viewpoint about AngularsJS framework, is it possible use it to develop all the front-end layer including soap and rest web service calls? Will it fit with our ERP application? I mean from a performance standpoint? because there is a lot of data that will be saved in the client side? Working with Javascript in the client layer? Doesn't it slow down the treatment inside the application?
Hey we are developing a hybrid application for data logistics which is connected through webservices and a Database with the ERP System.
We are using angularJs / Ionic Framework / Cordova
For saving data on the ClientSide we decided to use Localstorage / our own setter/getter Service and WebSql since we are doing offline Functionality too.
Our app is growing big and we have no Performance issues what so ever currently we have about 80 different views.
Hope this helps you
If we have a SPA App built with angularjs for example that use (REST API) web api service for it's requests is it ok or better qustion is should other mobile clients use same api for theirs request?
I would prefer having one API usable by multiple clients when possible so as to avoid having to duplicate code. The client should be responsible for making sure it can use your API (one API, multiple clients) rather than the API being responsible for making sure the clients can use it (multiple APIs for multiple clients).
I need to track usage statistics (such as which features are mostly used etc.) for my Windows Forms app that communicates with a WCF Service. Can anyone suggest how to achieve this using Google analytics? Also what is the best way to implement this, from the client app or the WCF service or both?
You can send data directly to Google Analytics using the Measurement Protocol.
The requests are sent via HTTP, so in terms of whether you should send it from the client or the server or both, the choice is yours. Do whatever is easiest.