I'd like to build some website using heavily CRUD operations (like most websites I guess). I saw that Quarkus provides a way to automatically generate CRUD operations for REST endpoints as shown here (based on PanacheRepositoryResource).
However, I'd love to use a Graphql endpoint instead of REST. Any idea how to automatically generate CRUD opertaions for Graphql in Quarkus?
Unfortunately this is not supported with GraphQL right now. There is an open feature request for it: https://github.com/quarkusio/quarkus/issues/20434 - feel free to watch it or chime in there.
Related
I have to create a rest api from scratch. I have already some experience with Jersey by doing mostly everything manualy.
I wanted to do it right now as this project is new. So I am currently trying the pet store sample that is available every time I am trying an openapi 3.0 online editor.
Using openapi-generator, I have generated the spring boot server for the pet store.
There are a lot of tutorial that will stop there. I don't understand where or how do I have to add my business logic code (database access, ....).
And after that I have a question, how is the specification update is done ?
With Spring Framework, you use Repository and Entity classes to handle data layer. And then add Service classes for business logic.
https://www.baeldung.com/spring-component-repository-service
Database (example in MySql): https://spring.io/guides/gs/accessing-data-mysql/
In client-server applications with spring-boot and angular. Most resources I find explain how to expose REST endpoint from spring boot and consume it from angular with an http client.
Most of the time, communicating in JSON is preconized, maintaining DTOs (DataTransfertObject) in both angular and spring boot side.
I wonder if people with fullstack experience knows some alternative avoiding maintaining DTOs in both front and backend, maybe sharing models between the two ends of the application?
Swagger would be a good tool to use here.
You can take a code-first approach which will generate a swagger spec from your Java controllers & TOs or a spec-first approach which will generate your Java controllers & TOs from a swagger spec.
Either way, you can then use the swagger spec to generate a set of TypeScript interfaces for the client side.
As Pace said Swagger would be a great feature that you can use. In this case plus having great documentation for the API endpoints you can sync object models between frontend and backend. You have to just use the .json or .yaml file of Swagger to generate the services and object models on the frontend side by using ng-swagger-gen.
Then put the command for generating services and object model in package.json when you wanna build or run your application for instance:
...
"scripts": {
...
"start": "ng-swagger-gen && ng serve",
"build": "ng-swagger-gen && ng build -prod"
...
},
...
So after running one of these commands you will have updated object models and if an object property name or type changed, add/remove object property you will get the error and you have to fix it first then move forward.
Note: Just keep in mind the services and object models will be generated based on the Swagger file so it always should be updated.
PS: I was working on a project that we even every code on the backend side was generated based on the Swagger file ;) so they just change the Swagger file and that's it.
This is a difficult topic, since we are dealing with two different technology stacks. The only way I see is to generate those objects from a common data model.
Sounds good, doesn't work. It is not just about maintaining dto's.
Lets say api changes String to List. It is not enough to update your typescript dto from string to string[]. There is logic behind string manipulation that now needs to handle list of strings. Personally i do not find that troublesome to maintain dto's on both sides. Small tradeoff for flexibility and cleaner code (you will have different methods in different dto's)
I have a Java client that allows indexing documents on a local ElasticSearch server.
I now want to build a simple Web UI that allows users to query the ES index by typing in some text in a form.
My problem is that, before calling ES APIs to issue the query, I want to preprocess the user input by calling some Java code.
What is the easiest and "cleanest" way to achieve this?
Should I create my own APIs so that the UI can access my Java code?
Should I build the UI with JSP so that I can directly call my Java
code?
Can I somehow make ElasticSearch execute my Java code before
the query is executed? (Perhaps by creating my own ElasticSearch plugin?)
In the end, I opted for the simple solution of using Json-based RESTful APIs. Time proved this to be quite flexible and effective for my case, so I thought I should share it:
My Java code exposes its ability to query an ElasticSearch index, by running an HTTP server and responding to client requests with Json-formatted ES results. I created the HTTP server with a few lines of code, by using sun.net.HttpServer. There are more serious/complex HTTP servers out there (such as Tomcat), but this was very quick to adopt and required zero configuration headaches.
My Web UI makes HTTP GET requests to the Java server, receives Json-formatted data and consumes it happily. My UI is implemented in PHP, but any web language does the job, as long as you can issue HTTP requests.
This solution works really well in my case, because it allows to have no dependencies on ES plugins. I can do any sort of pre-processing before calling ES, and even post-process ES output before sending the results back to the UI.
Depending on the type of pre-processing, you can create an Elasticsearch plugin as custom analyser or custom filter: you essentially extend the appropriate Lucene class(es) and wrap everything into an Elasticsearch plugin. Once the plugin is loaded, you can configure the custom analyser and apply it to the related fields. There are a lot of analysers and filters already available in Elasticsearch, so you might want to have a look at those before writing your own.
Elasticsearch plugins: https://www.elastic.co/guide/en/elasticsearch/reference/1.6/modules-plugins.html (a list of known plugins at the end)
Defining custom analysers: https://www.elastic.co/guide/en/elasticsearch/guide/current/custom-analyzers.html
I want to expose CRUD operations to MySql via REST apis. I have just started exploring Spring. I have found Spring rest data to be a good fit for this.
But there is only one problem, automating the generation of java model, repository classes, etc,. What are the tools available that can do this? I want this to be done without any interface, preferably via maven.
I'm working on an application acts as an event service bus for integrating various legacy components....The application utilizes a data store to audit all events and requests sent between systems as well as to store metadata about bus-subscribing endpoints...etc. I want to utilize CouchDB as the data store since it already has many of my application's requirements built-in (REST API, replication, versioning metadata documents...etc). Now here's how my app stack looks like:
[spring-integration filters/routers/service activators]
[service layer]
[dao layer]
[database]
With the database being CouchDB, I guess the the DAO layer would be either Ektorp Java library or a simple REST client. Here's my question though: isn't building a DAO layer with Ektorp kind of redundant? I mean, why not just use a RestTemplate in the service layer that talks to the views and design documents in CouchDB and save me some coding effort?
Am I missing something?
Thanks,
I don't know if you have tried it yet, but LightCouch in many ways would act like a REST template. Beside handling document conversion to your domains, and design docs / views, you may use it as a client to CouchDB anywhere in application such as a DAO or service layer.
If you roll your own you will have to implement the json parsing / mapping of view results and what not.
Besides efficient view result parsing / object mapping which might be tedious to develop yourself, Ektorp will also help you with view design document management through annotations.
Ektorp has many more features that I think you will appreciate when you dive deeper into CouchDB.
If your app only will perform simple gets of individual documents, then rest template might be enough. Otherwise I don't think you will safe time doing it yourself.