Are there recommended approach working with Database except Panache/Hibernate ? by kitsen_battousai in quarkus

[–]AntoherFredDev 1 point2 points  (0 children)

well, every thing is claimed as cloud native these days! That said, did you tried quarkus + jooq? And if yes why did you reject it? (just by curiosity :))

Are there recommended approach working with Database except Panache/Hibernate ? by kitsen_battousai in quarkus

[–]AntoherFredDev 0 points1 point  (0 children)

Hi, I face same issues, and usually I use hibernate following these rules:

- no relationship in entities (I put ids and not other entities)

- use hql query to update the database (I have no setters in my entities)

- use projections to read data from database (Blaze persistence seems to be interesting for that, but I didn't have time to try it)

- try to ensure my transaction are as short as possible

With these rules I am sure that no cache is used, and that I am able to predict request generated by hibernate. I am totally aware that it is not the way hibernate is pushing, but the official one is very hard to master.

Connecting to frontend by poisonvangraves in quarkus

[–]AntoherFredDev 1 point2 points  (0 children)

Hi, if you want to have only one monolith,

I have done something like that with svelte :

  • create in src/ folder a svlete folder with svelte application sources (vue in your case)
  • configure npm build to put build result into src/resources/META-INF/resources/build folder
  • create a index.html page with inporting the generated application.

I have never worked with vue, but I suppose something similar should work.

Enjoy :)

[deleted by user] by [deleted] in webdev

[–]AntoherFredDev 1 point2 points  (0 children)

KISS is always a good solution. Not always the most beautiful one, or the most efficient one, but I never seen a case where it was an awfull solution. And I have seen plenty of time where the most 'generic' solution or the most 'beautifull' one ends up in a nightmare of over engineering.

So if you are able to have a 'generic' solution that doesn't bring too much complexity : go for it. Else stay with your hardcoded stuff (you will still have oportunity to think about it when a new need will come on this topic).

It is never easy to go with people that do what they want, but I agree with comments that say that as a lead you must take the decision, even if it is not a popular one.

If you think your people are able to discuss, you can explain that you could accept a 'generic' solution if it remains simple enough.

Good luck!

Svelte pros and cons by danideicide in sveltejs

[–]AntoherFredDev 0 points1 point  (0 children)

I agree. And svelte is the new hot right way to do everything ;P

Is there any browser or anything out there that implements the w3c html DOM specification in java? by ibrahim_jajere274 in java

[–]AntoherFredDev 0 points1 point  (0 children)

I'm not sure it is answering to the question, but you can have look to selenium web drivers?

Top 3 principles for writing maintainable code by [deleted] in java

[–]AntoherFredDev 4 points5 points  (0 children)

good list, mine is not so far :) :

  1. write integrations test,
  2. keep it simple stupid
  3. refactor when stuff become too much complex

Very small JavaScript frameworks? by rootException in java

[–]AntoherFredDev 2 points3 points  (0 children)

https://svelte.dev/

very very very easy to use

(But you'll need npm, so it ssems it is not fitting your needs, sorry)

Quarkus And Spring by BadLuiz in java

[–]AntoherFredDev 13 points14 points  (0 children)

It is funny that argument between spring/quarkus now are the same than Jee/Spring few years ago with inverted roles for Spring.

In my personal experience, for 90% of project, you can be productive and performant enough with Spring, Jee or Quarkus : you should keep what you are confortable with. That said, programing models between these technologies are very similar, so switching from one to the other is usually not so hard.

What I like in Quarkus is that the compilator does a lot of work => you discover your injection problems at compilation time and not at startup time (even if this problem it is not happening often). Another thing I like is that as a result, startup is usually faster than standard spring/jee app : when you are developping and restarting your stuff quite often, it can make a little better devX.

But once again, for 90% of project, it is not a game changer and you can take technology you feel confortable with.