Thanks! Glad you found it helpful.

Hey, not really if your app is small or config changes are not frequent or you have an alternate way of reading those configs say by making a rest call or some custom IO ops or any other solution. In this context, having a config server allows us to scale, xentralize and standardize the config related operations like dynamic refresh and so on.

@@the_codealchemist what i mean is that, do you need it running locally. Can't the client app fetch it straight from the server itself without relying on another client?

Glad it was helpful!

Thanks, appreciate the feedback!

Yes we can..will give it a try.

You're welcome! I'm trying my best to keep things simple and straightforward.

Will try my best to do one on JWT!

Brother, I am waiting for your JWT tutorial in this style. I want to believe that you will make it soon)))

Thanks for the kind words, I'm happy you found it useful!

I'm glad you found it helpful!

I just couldnt get the producer there at the end to allow me to enter user id or anything. it displayed the message to the console then went by it telling me the cluster id and the producer id then blanks out.

I can have a look if you could share the code

Glad you found it helpful!

Thanks!

Hi, I think you can explore docs.oracle.com/javaee/7/api/javax/persistence/AttributeConverter.html

Thanks!

This is an interesting scenario! I'll try to include some explanation on how to achieve this kind of read-only schema functionality at the application level. Although, I have not tried these myself. Please let me know if it works! I think you can explore Hibernate's StatementInspector which perhaps can do what you want vladmihalcea.com/hibernate-statementinspector/ Basically in the inspect method you get the sql query before it gets executed so there we can block Insert, update, delete queries on EFG schema with some String operations. Second, we can try to use Hibernate/JPA Listeners and block update queries with custom logic medium.com/jpa-java-persistence-api-guide/hibernate-v6-event-interception-250ae115f0db

Captions are actually numbered hence not in the title

Great content. Simple and crisp 👌

Yes it is generally recommended unless you have a usecase of lazy loading

Glad it was helpful!

What a coincidence 😁

You're welcome!

Glad it helped!

Thank you for the great question..in fact this could be a great video. You're correct if secret is updated but not refreshed in the application, it could cause problems depending on the task. I can think of a couple of ways to handle this: 1) Instead of having a cron job, we can configure the secret to be refreshable in application config file with a time interval which will cause Spring Cloud Azure to periodically check the secret from Azure. learn.microsoft.com/en-us/azure/developer/java/spring-framework/secret-management 2) We can also use an actuator refresh endpoint but it would be manual task to hit the refresh endpoint whenever the secret is rotated or refreshed. 3) We can go via exception handling route e.g. keep using the key and if you get an exception retry the operation by reading the updated secret(Not a fan of this approach though!) 4) Another way could be listen for Azure events for secret changes and react in real time to refresh the secret.

@@the_codealchemist thank you very much!

there might be one more way which is like implementing a cache which will fetch the secrets from the key vault after a certain interval and the application will fetch the secrets(in our case the db credentials) from the cache. this approach will solve two important problems first one is secret rotation and the second one is the latency issue.

​@@TheSAM_95 Thank you very much for the suggestion! There is definitely a benefit to using a cache, but I see a small issue here. Imagine we have a secret that is needed for every request, like an API key. If someone rotates the secret, our application would still be using the old one until the cache refreshes, which could lead to failures. If we set the cache to check the key vault regularly, we end up with two challenges: Delay: There is always a gap between when a secret changes and when the application gets the new value, potentially causing downtime for critical requests. Overhead: Checking the key vault too frequently could add unnecessary load, but checking less often makes the delay problem worse. One possible improvement might be an event-based update, where the application listens for secret changes and refreshes the cache instantly, something like using the Observer pattern. Not sure if this would work here, but it could solve the delay issue. Maybe Azure's Event Grid (learn.microsoft.com/en-us/azure/event-grid/overview) in combination with Key Vault can be used.

Sure, I'm currently working on Spring Security but as I get some time I will try to pick it.

Much appreciated!

Your observation is spot on..true even though it avoids the server starts but someone will have to call the endpoint. In business critical apps and sensitive orgs, there's generally a release process before pushing anything to production sort of a 4-eye check so there could be an internal process to indirectly hit the busrefresh endpoint after the approval for instance. However we can make it automated programmatically by listening to some events. Webhooks are generally the preferred way to make such things fully automated which can be used with Spring boot. Or K8s configmaps for instance if you're using Spring Kubernetes project.

Glad you liked it! More hands-on videos coming soon..

Thanks for the feedback. I'm taking a note, will try to pick the idea.

Looks like solution/comment I pasted got deleted. :)

Thanks for your feedback! Multi tenancy is a broad topic, do you have anything specific in mind?

You're most welcome

Not a mistake but an end-to-end video since as we go on with the playlist it's all about services.

Thanks for your feedback. However I didn't get your point why this is not relevant? The agenda is Spring JDBC which is still useful for basics. Many old apps still use Spring JDBC code so it's good to know especially when someone is starting with Spring Data. There are other videos in the same playlist which cover different aspects like a CRUD api using Postman, Spring Data JPA and Spring Cloud. Hope you find what you're looking for. Let me know if I got your comment right.