I'm developing an app deployed in GAE, simple for this moment. This app is the backend of other app.
Internally, this app have a few modules (this is not important here) that they communicate with rest apis (for other reason).
And the question that I'm thinking is: I was beginning to write API (to outside) using gRPC and EndPoints like GAE docs says, when I thought that if I could have really advantages if using gRPC and not REST like internally.
I have been spend a lot of time searching that really advantages that offers gRPC about REST, but I don't find it.
Why Google recommended gRPC? Is faster than REST?, (from my point of view is most simple to write)
You know any test about speed with both technologies?
I will thanking any help.
You can use GRPC today on AppEngine's Managed VM platform as both a client and a server. If you want load balancing you need to use TCP/IP load balancing and have GRPC servers terminate TLS for you.
GRPC does not yet work on AppEngine standard but we're working on it. For more questions hit up the mailing list.
Related
I have a single screen desktop application developed in Java. It is a tool to convert files, given a file in .abc format, the tool converts it to .xyz format. Basically the tool works offline and acts as a translator to convert file from one form to another.
So now, to improve the infrastructure, there are discussions to move the tool to Kubernetes or to provide REST services for the file conversion. I completely have no idea about the containers nor the REST APIs as I am a front-end developer.
More about the tool, as I told earlier, the tool is a single page application, very light doing very minimal job, totally used by 200 users approximately. So, this being the shape and size of the application, which one would be the best approach to go with and why? Basically, I am looking for a short evaluation report of Kubernetes vs REST service and architecture recommendation with reasons.
Currently your application is a standalone application which is quite an old concept.
I can mention high-level changes needs to be done when your file conversion logic would be exposed over Rest Api in Kubernetes world.
you can go through one by one following mentioned areas to get a better understanding design-wise:
java code would be a backend code and its public methods that take inputs from UI actions will be exposed over rest API.
There are multiple rest API's (jersey, rest easy, etc or spring/spring-boot framework also provides rest API support) that you can go through any of them to get an understanding.
once your backend is exposed over the rest API then it needs to be containerized means your backend will be running under the container. Can go through docker documentation and can build one sample containerized app. There is huge material present in this area.
once your backend is containerized then it will be installed in a Kubernetes cluster
Kubernetes is basically a container orchestration tool and it's quite a wide thing. you can through its official documentation for basic understanding.
SPA will be running on a client machine like today also you are able to launch from your desktop but it will communicate with the Kubernetes cluster where your application is presently packaged in a container.
References:
docker :
https://docs.docker.com/
Kubernetes :
https://kubernetes.io/
Kubernetes OpenAPI specification is hosted here.
https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec
Additionally, various client APIs for the Kubernetes is provided here:
https://kubernetes.io/docs/reference/using-api/client-libraries/
Using the OpenAPI specification, I am able to generate the server code, which provides the REST services. However, the applications using these K8s client APIs (written in either language - Go, Java, etc.) do not use these REST API directly.
My objective is to mock the K8s server to use in the test automation and build a controlled environment to create various test scenarios.
Is there any ready-to-use Kubernetes mock available? If not, how we can interface the client APIs with the above OpenAPI generated REST server? This way, the applications shall continue to use the client APIs but internally, they will be communicating with the mocked K8s server and not the real one.
Please help with the options.
.
Not really a direct answer to your question, but most solutions i have seen implemented are not trying to mock the k8s API but are really using it through either k3s (from rancher labs) or KinD project (official way)
You then connect to it like a normal kubernetes cluster
I'm trying to deploy my first Vue.js application on Heroku, but I need some clarification.
My app is a very simple client consuming REST service API.
I deployed the REST service on a Heroku dyno and now I need to also deploy my front-end application.
Is it possible to install client app on the same dyno? Is it a good practice, or should I deploy the client as a separate application?
What is the "real-world" production approach?
NOTE REST APIs are based on Java/Spring MVC.
It is certainly possible, and can keep your dyno costs down.
I answered a similar question here. That specific answer may or may not be suitable to your needs depending on what server technology you are using etc., however, the general idea is that you can certainly maintain multiple parts of your app within a single git repo that gets deployed to a single Heroku app.
Such a single Heroku app may or may not consist of multiple Process Types which may each run on one or more dynos.
I want to develop my iPhone app but I am not sure what could be the options I have for hosting database and webservice to communicate with my iPhone App. Could someone please suggest me what could be the best way to go for this?
I know how to build everything but never come across this situation. I have been working in environment where we ask Admin to give us Server where we host everything but if I want to do it myself and don't have server infrastructure what could be the options do I have? Do I need to purchase from web hosting provider?
Thanks.
From my experience, I've developed back-end part for iPad client. It was REST, ASP.NET Web API (WCF Web API) and as database on back-end MS SQL Server and MySQL.
Anyway for mobile clients you can freely use REST. It can be ASP.NET Web API from .NET or other libraries that help to make REST services for example from Java.
REST is good consumed by mobile client applications. And then from client application perspective, it's no matter what database back-end will have.
Speaking about hosting it also depends from requirements to back-end. When you have no server infrastructure, you can use cloud PaaS like Amazon AWS (EC2) for example. Or host server it by yourslef.
Hosting an application on a web application server e.g. JBoss automatically brings in lots of app server specific functionalities with it e.g. security, clustering & load balancing etc. I have a situation where I have to develop a server app with which, legacy apps can talk to over TCP/IP socket as well as be highly available. Initially, I had though of using JBoss app server to leverage its clustering support for HA. However, I am not sure whether it would be possible to connect to a JBoss web app using pure TCP/IP sockets from both java and non-java apps.
What is the best way to achieve this without using web service or Http approach?
UPDATE: I am specially interested to know how legacy apps will connect to the hosted web app through TCP/IP socket.
A really simple solution to bridge the two worlds would be to add a simple Java server which maps the old TCP/IP requests to HTTP requests. This is probably a pretty braindead task, so this "server" will be simple to write and maintain. Also, this server won't need as much power since it just accepts and forwards connections (no business logic or DB code).
On the JBoss server, you develop like you normally would. The legacy apps connect to the little bridge server which passes the requests on to JBoss and translate the result back.
This ensures that you're building for the future: When new apps are developed, they can connect directly to JBoss and use all the great HTTP features.
There's no reason why you can't open up a normal socket in (say) a servlet application hosted in JBoss.
You can then get a byte stream from this. The headache is then to decide on a platform-independent representation of your messages, such that your client end can format and send such that the JBoss-hosted end can read. But it's all perfectly feasible.
I would implement a very simple http (1.0) client.