I had some trouble wording the question, but basically, I have found it common, where I work, to create a Java Spring Rest API that connects to a database and a front end application uses that API (web-app -> service API -> database). This couples the application service api to the data store and is often specific use case for the front end application. I see many service APIs creating the same get calls to the same database. This seems wrong to me.
I believe it would be better to create an API for the database itself, then run the service API to that. (web-app -> service API -> datastore API -> database). This would allow all services to access the database without coupling to it directly and having to manage access to that database for 30 applications. It would also allow any application that doesn't need anything other than the data to just use the existing datastore API. I remember an article about how Amazon requires an API for every data store and this is how I would see that being handled.
Is the idea of having a data store API and connecting to that using a service API the right mindset? Or is there some other way I should be handling this?
Reading what you just wrote it seems to me that what you have is a "microservices done wrong", as I can understand you have a few applications accessing the same database/datastore, from a microservices perspective it's wrong.
Each application should have its own database split in boundaries if any application needs to query/update the other's application data it uses an API rather than accessing the database directly.
The bottom line is, instead of having an API to access a single database each application should limit itself to its own boundaries and access its own database.
Of course, one size doesn't fit all but I do belive it's a good guideline.
Related
Suppose i have a service that make multiple api calls to multiple micro services
Currently i am fetching all required endpoints from database and setting them as system property.
But i want to remove this db call and at the same time externalize the same.
Can you please suggest me best ways to externalize these endpoints?
In micro-service based architecture, ideally what you need is service registry and server side service discovery pattern to tackle multiple service calls.
If you are sure that your api calls are never gonna change, then keeping it in .properties file make sense, but again if they change you have to re-deploy your service.
You need to get the API end points from a Directory which will have the latest API end points. This has to be a global DB or Directory. Try using JNDI.
Android web view is not what i looking for.Android interface is completely different from the web view.Do I want to make my Web and Android app to use REST web services? I am designing my web using springMVC.
What data are you expecting to exchange from and to the website? Does this mean you will be adding, deleting, updating the data or just simply retrieving
Regardless I would look at Json data if your website is capable of providing that. If Yes, I would recommend using retrofit to download the data onto your application and use it however you like. Retrofit is also capable of working in conjunction with CRUD methods as well.
We have a api project written in JAVA using spring hibernate and reading data from MySQL. Recently, we added another data source as BigQuery, therefore we want to allow user to call certain apis to query data from BigQuery - order count from orders table in BigQuery using JAVA api client. Looked at the github sample, but not clear about how to setup and access.
Also found this link but not sure about registering a web application, etc. Please advise.
Update: Imagine this as a web application which shows count of orders in the last 5 days if I select a merchant. but the orders table is in BigQuery. My web application calls-> java api layer which calls -> bigquery using client library -> populates the response as a json -> web application receives the count of orders.
I feel the hiccup is in authenticating using GoogleCredential. Generated a new Oauth Client Id which provided a client_id and client_secret. But still it is not able to authenticate to the project and give results.
Thanks.
Since your question is generalized, I believe what you need is to understand Google's BigQuery on how it works, how to setup the data etc.
Once you setup the data in BigQuery, you can access BigQuery by using a web UI or a command-line tool, or by making calls to the BigQuery REST API using a variety of client libraries such as Java, .NET or Python
You also haven't mentioned that whether you have gone through the basics.
I hope this link will be helpful in understanding how to import data to BigQuery and setting up the data, querying etc.
Use Service Accounts to connect to your BQ.
And please be aware that the response time will be 2-3 seconds as this is a big data tool not a real time db for web use. Not sure if that's how you want your web application to work. You may need to cache the number in your local database.
Currently i have a website offering some product. The webserver sits on the same system as the database and directly accesses it to retrieve the required information for the HTML frontend. Now i think it is good to separate the database from the webserver via an API server. The reason why i want to use an API server is that it might be possible that future applications, other than the website, will need access to the information on the system.
The system which i want should consist of the following components:
A database which will store all the required information.
An API server which will be implemented in Java and should use oauth2 for authorizing user requests. The API server will have the only direct connection to the database.
A webserver.
So basically what i have in mind is that i want to build my website on top of that API server. The user will register/login/... over the website and the website implementation will internally query the API server as a webservice on behalf of the user. The API server would then return the data from the database. That way the HTML frontend is just an application using the API server and will never itself be in direct contact with the database.
I think that this is an often encountered problem for which a good solution exists. I am unsure if this solution is the way to go though. Could you help me out and/or point me in the right direction from here?
Thank you.
As far as I know, it is not advisable to have a separate API server for a couple of reasons: decreasing performance and increasing compexity of a system. So basically you should avoid this type of solution for as long as possible.
You should definitely read M. Fowler: "Enterprise Architecture Patterns" for inspiration.
Returning to your question: have you considered making this API layer as a module (library)?
If I haven't convinced you, try reading Java RMI documentation (http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html)
I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.
Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.