2026-02-20 18:32:00
v1.2.0 is all about making the generator smoother to use in real projects: more predictable migrations across databases, fewer Docker Compose surprises, and better JSON support for collection-based fields. Along the way, there’s also internal refactoring to keep the codebase easier to maintain and extend.
This release improves Flyway script generation so migrations behave more consistently across MySQL, MariaDB, MSSQL, and PostgreSQL. The goal here is simple: fewer “works on my DB” moments when switching environments or adding a second database target.
The JSON type has been extended to better match how modern APIs model data. In addition to single-object JSON fields, you can now generate JSON columns for collections:
JSON<List<Type>>JSON<Set<Type>>This makes it much easier to model things like tags, attributes, nested configs, and other “structured but flexible” data without bending the domain model.
If you’ve ever had your Spring Boot container start before the database is ready (and crash/retry until it is), this update fixes that at the Compose level.
.openapi-generator-ignore to avoid regenerating/overwriting:
pom.xmlREADME.md, Readme.md, readme.md
To make it easier to see the expected output and integration flow, there’s now a dedicated demo repository:
If you’re upgrading from earlier versions, v1.2.0 should be a drop-in update in most setups. The main benefits will show up immediately if you target multiple DBs, rely on JSON-mapped fields, or run everything through Docker Compose.
Repo: https://github.com/mzivkovicdev/spring-crud-generator
2026-02-20 18:31:57
A company needs storage for their offices and departments. This content is private to the company and shouldn't be shared without consent. This storage requires high availability if there is a regional outage. The company wants to use this storage to back up the public website storage.
Let's get to it!
Action plan:
1 . In the portal, search for and select Storage accounts.
2 . Select + Create.
3 . Select the Resource group created in the previous lab - "sapublic". Set the Storage account name to private. Add an identifier to the name to ensure the name is unique. Select Review, and then Create the storage account.
4 . Wait for the storage account to deploy, and then select Go to resource.
5 . This storage requires high availability if there is a regional outage. Read access in the secondary region is not required. We have to configure the appropriate level of redundancy. To this, in the storage account, in the Data management section, select the Redundancy blade. Ensure Geo-redundant storage (GRS) is selected. Refresh the page. Review the primary and secondary location information. Save your changes.
Action plan:
2 . For testing, we will upload a file to the private container. The type of file doesn’t matter. A small image or text file is a good choice. Test to ensure the file isn’t publicly accessible. To do this, Select the container. Select Upload. Browse to files and select a file. Upload the file.
3 . Select the uploaded file. On the Overview tab, copy the URL. Paste the URL into a new browser tab. Verify the file doesn’t display and you receive an error.
Action plan:
1 . Select your uploaded blob file and move to the Generate SAS tab.
2 . In the Permissions drop-down, ensure the partner has only Read permissions.
Verify the Start and expiry date/time is for the next 24 hours. Select Generate SAS token and URL.
3 . Copy the Blob SAS URL to a new browser tab. Verify you can access the file. If you have uploaded an image file it will display in the browser. Other file types will be downloaded.
Action plan:
1 . Return to the storage account **. In the **Overview section, notice the Default access tier is set to Hot.
2 . In the Data management section, select the Lifecycle management blade. Select Add rule.
3 . Set the Rule name to movetocool. Set the Rule scope to Apply rule to all blobs in the storage account. Select Next.
4 . Ensure Last modified is selected. Set More than (days ago) to 30. In the Then drop-down select Move to cool storage. As you have time, review other lifecycle options in the drop-down.Add the rule.
Action plan:
1 . In your storage account, create a new container called backup. Use the default values.
2 . Navigate to your publicwebsite storage account. This storage account was created in the previous exercise. In the Data management section, select the Object replication blade. Select Create replication rules.
3 . Set the Destination storage account to the private storage account.
Set the Source container to public and the Destination container to backup. Create the replication rule.
4 . Optionally, as you have time, upload a file to the public container. Return to the private storage account and refresh the backup container. Within a few minutes your public website file will appear in the backup folder.
Mission Accomplished!
2026-02-20 18:20:05
There's a specific kind of pain that only developers who've built e-commerce from scratch truly understand. You start the project feeling confident, maybe even a little cocky. Then, slowly, the features start stacking up, and you realize that what you thought was "almost done" was really just the beginning.
That was me, not too long ago.
The first time I worked with a team to build an e-commerce platform from scratch, we genuinely believed we were ahead of schedule after getting the product catalog sorted. We were patting ourselves on the back, thinking the hard part was over.
Then reality kicked in.
We still had order management to figure out. Then shipping logic. Then inventory. Each feature we added felt like pulling a thread on a sweater; one thing would change, and something else would unravel somewhere else in the system. It was a lot.
But the thing that really kept me up at night wasn't the features themselves. It was the realization that if the client ever came back asking for something new, like adding a discount engine, a loyalty system, anything, we'd be in serious trouble. Scaling it or adding new features would have been a nightmare. Every small improvement meant rewriting chunks of the system, and every new integration felt like walking a tightrope.
I knew there had to be a better way. I just hadn't found it yet.
About a year later, a friend of mine landed a contract to build a fashion e-commerce platform, but not just any platform. This one needed a loyalty system with a gamified experience built right into it. Points, rewards, levels, the works. He brought me on to handle the backend, and I knew from day one this wasn't going to be a simple project.
My first thought was Shopify. Use their API for the commerce side, then build the loyalty system as a headless layer on top. It made sense on paper. But when I actually started looking at what that would cost, both in API limitations and actual money, I knew I had to find something else.
That's when I stumbled across MedusaJS.
The timeline was tight. We didn't have months to figure things out, so I needed a tool that was quick to get running, flexible enough to handle custom business logic like gamification, and solid enough to avoid falling apart when the client wanted changes down the line. MedusaJS seemed to tick every box, so I went with it.
Before I get into MedusaJS specifically, I want to be honest about something, because I think a lot of developers underestimate what they're signing up for when they decide to go fully custom.
Product and inventory management alone is way more complex than it looks. You're not just storing items in a database. You're dealing with variants, stock levels per location, pricing rules that change based on customer groups, bundles, and more. One small tweak can ripple through your whole system in ways you didn't anticipate.
Then there's payments and shipping. Every provider has their own API with its own quirks and edge cases. I've seen a poorly handled webhook take down an entire checkout flow before, and it's not a fun conversation to have with a client.
And once you're past all that, you still have to think about scale. Will this hold up if traffic doubles? If the product catalog grows to 10,000 items? If a new region needs to be supported? These aren't hypotheticals; they're inevitabilities if the project succeeds.
The truth is, a lot of the core e-commerce logic has already been solved. When you build from scratch, you're not being clever. You're just doing extra work to arrive at the same destination.
When I was scoping out the fashion project, I mapped out three realistic options.
The first was building from scratch again. I'd done it before, I knew the pitfalls, and honestly, I wasn't interested in going through that again. Full control, sure, but at what cost?
The second was going with a SaaS platform like Shopify or BigCommerce. Quick to spin up, reliable, tons of integrations. But the moment you need something custom, and with a gamified loyalty system we definitely did, you start hitting walls. And the pricing model isn't always friendly when you're building for a client on a fixed budget.
The third option was an open-source headless solution. That's where MedusaJS comes in. It gives you the commerce foundations that would take weeks to build yourself, while still letting you own the architecture and extend it however you need.
For this project, that third option was the only one that made sense.
I don't want to make this sound like an ad, so let me just be practical about what I noticed.
The headless architecture meant I could hook up whatever frontend the project needed without being forced into a specific stack. No monolithic walls to work around.
The core commerce features, products, variants, orders, and payments, were already there out of the box. That alone saved us weeks. I didn't have to build a cart system or figure out order state management from scratch. It was done, tested, and working.
The extensibility is where it really shone for this project, though. Because we were building a custom loyalty system, we needed to plug into things like order completion and customer activity without rewriting the core. Medusa's architecture made that feel natural rather than like a hack.
And when I got stuck, which happens, the documentation and community were actually helpful. That's not something I take for granted.
I want to be real here too, because I think a lot of "here's a tool I used" posts leave this part out.
MedusaJS has a learning curve. Not a brutal one, but it's there, and it requires you to actually think differently about how you structure your backend.
The first thing that tripped me up was the event-driven architecture. I was used to just stacking logic where it made sense inline. But Medusa works through events and subscribers; when an order is placed, you don't handle the side effects right there in the controller, you emit an event and react to it elsewhere. Once I stopped fighting that pattern and started leaning into it, everything felt cleaner. But that mental shift took a minute.
Then there's how the modules connect through what Medusa calls "links." Products, orders, customers, and payments are all separate modules with defined relationships. I initially wanted to treat it like one big coupled system, which is what I was used to. That instinct will get you into trouble. Once I respected the boundaries the framework was trying to draw, things clicked.
The service layer and dependency injection were also different from what I was used to. Instead of just importing something directly, you resolve it through the container. It feels a bit ceremonial at first, but it's there for a good reason; it keeps everything modular.
Integrating Paystack is probably the best example of all of this coming together. I didn't rewrite the checkout flow. I extended the payment provider and plugged into the existing workflow. The moment that worked, I finally understood what Medusa was going for: you extend it, you don't rewrite it. That's the whole philosophy.
Looking back, the learning curve was really just about understanding how Medusa thinks about commerce architecture, not about fighting bad design. And compared to what I went through building from scratch that first time, it felt structured and manageable in a way that actually gave me confidence as the project grew.
If you're a developer working on anything beyond a basic storefront, something with custom business logic, unique integrations, or a client who's going to have evolving requirements, I'd genuinely recommend at least giving MedusaJS a look before you commit to building it all yourself.
You might be surprised how much ground it covers before you've even written a single line of custom code.
Have you worked with MedusaJS or gone through a similar journey choosing the right backend for an e-commerce project? I'd love to hear how it went. Drop a comment below.
2026-02-20 18:16:20
On the surface, many business websites look “done”, with all the usual boxes checked.
Yet visitors often leave without acting, not because the business lacks credibility, but because the website does not guide them forward.
This gap is rarely about bad intentions or lack of effort. In many cases, the site was built to explain the business, not to guide the visitor. It shares information, but it does not help people decide what to do next. Visitors scroll, skim, nod along, and then leave.
Not because the business is not credible, but because the path forward is not clear.
This is where the conversation around information focused vs conversion focused websites becomes useful.
Both have value. Both are common. But they serve very different roles. One is designed to inform and reassure. The other is designed to gently lead, build confidence over time, and invite action without pressure.
Understanding the difference helps you move from “our website looks fine” to “our website actually supports our goals”.
In this article, we will look at how these two approaches work, why many well designed websites still underperform, and how small, thoughtful shifts can improve clarity, trust, and momentum.
No hype, no tricks. Just practical insight you can apply, whether you are refining an existing site or planning the next one.
Information focused websites work like digital brochures. Their main role is to explain, educate, and provide context. They help visitors understand who you are, what you do, and how you think. Selling is not the primary goal here.
These sites usually include familiar pages like a homepage, an about section, service pages, and often a blog. Their strength lies in clear, well written content.
Testimonials, case studies, and examples of past work build trust and credibility over time.
You will often still see contact forms or newsletter sign ups, but these act more as a soft entry point than a strong push toward action.
Key characteristics of information-focused websites:
An informational site is ideal for early stage awareness and education, but without strategic calls to action or persuasive design elements, visitors may leave without engaging further.
Unlike a site that simply presents information, conversion focused websites are built with a clear purpose: helping visitors take a meaningful next step.
That might be getting in touch, requesting a quote, booking a call, or starting a trial.
A conversion focused site works quietly in the background, guiding visitors from curiosity to action at any time of day.
Content, structure, psychology, and technical performance all work together to reduce friction and make the next step feel natural rather than forced.
A conversion focused site behaves more like a sales engine than a brochure. It is designed to persuade, remove friction, and inspire action.
Understanding these differences allows businesses to choose or combine strategies depending on the stage of their customer journey.
Remember, many sites start as informational and evolve into conversion driven engines as they grow.
Our brains process visual information rapidly, and first impressions are difficult to undo.
Google’s study on visual complexity and prototypicality demonstrated that users evaluate a website’s aesthetics in 17 to 50 milliseconds.
Two factors were most influential:
Use generous whitespace, consistent fonts, and straightforward navigation. Resist the temptation to cram every detail on the home page.
Instead, prioritise the most important information or call to action and let supporting details live on secondary pages.
Provide a familiar structure: a logo in the top left, navigation across the top or down the left side, and content arranged in manageable sections so visitors can orient themselves quickly.
Most people scan rather than read. They look for cues, headings, and familiar patterns. When the structure is clear, visitors feel in control and trust the experience. When it is not, even good content can go unnoticed.
Here are a few practical ways to create that clarity:
A clear structure does not push visitors. It supports them. When navigation feels natural, people spend less energy figuring things out and more energy engaging with what you offer.
On an information focused site, content is your product. Invest in well researched articles, FAQs, how to guides, and case studies that anticipate visitors’ questions.
Provide context on why your service exists and the problems it solves. Use storytelling and real examples to humanise your expertise.
For conversion focused pages, copy needs to be concise, benefit oriented, and persuasive without feeling manipulative. Show visitors what they will gain by taking action.
Use simple language, action verbs, and credible support. Make sure you address common objections or questions clearly near the call to action.
If you gather user data (for example contact information), explain how you will use it to add value and keep it secure. Transparency builds trust.
No amount of persuasive design will work if visitors do not trust you.
A study examining trust and website conversion found that user trust is a significant predictor of conversion, accounting for over 57 percent of the variability in consumer conversion.
Simply put, more than half of the decision to act hinges on whether visitors believe your site and organisation are credible.
The same research notes that trust is shaped by the perceived usability and quality of a website, smooth navigation, clear information, and technical reliability, all of which reinforce trust.
Trust can also be amplified through social support. When other users share information (for example ratings or reviews), visitors perceive greater authenticity and are more likely to engage.
Trust is built through many small signals working together.
When visitors can quickly see who you are, how you work, and what to expect, they are more likely to feel comfortable engaging further.
Here are some practical ways to build trust:
Once trust and clarity are established, conversion focused pages must guide visitors toward a single goal.
While there is no universal formula, several principles show up consistently in strong performing pages.
Visitors abandon tasks when they encounter friction. Minimise the number of steps required to convert.
On e commerce sites, this might mean reducing checkout fields and allowing guest checkout. For lead generation, keep forms short and avoid asking for information you do not need.
The trust study emphasises anticipated website usability, meaning users’ expectation of how easy it will be to navigate and accomplish tasks. Ease of use fosters trust.
Calls to action should be specific and emphasise the benefit to the user, for example “Get Your Free Audit” instead of “Submit”. Use contrasting colours so calls to action stand out, while staying consistent with your brand palette.
Support the call to action with concise copy that answers “Why should I do this?” and addresses likely objections.
Place trust signals, such as security icons, privacy assurances, and customer testimonials, near forms and key buttons.
Remind visitors that their data is safe and that others have benefited from your service. Clear reassurance lowers perceived risk and increases the likelihood of action.
Avoid over hyping benefits or hiding important details. Transparent, straightforward messaging builds credibility.
Frame features in terms of outcomes. If there are costs or commitments involved, state them clearly. Deceptive tactics may produce short term wins but damage trust long term.
A slow or glitchy site undermines trust and kills conversions. Fast loading pages signal care, reliability, and respect for a visitor’s time.
Compress images, minify scripts, and use caching or a content delivery network to keep pages quick.
Monitor performance across devices. What feels snappy on a desktop may lag on mobile.
While the distinction between informational and conversion focused websites is useful, the most successful digital experiences integrate both elements.
Education lays the groundwork for trust and positions your brand as an authority. Conversion opportunities then allow interested visitors to act without friction.
Here are strategies to weave these approaches together:
When information and conversion support each other, your website stops feeling fragmented. It becomes a single, coherent experience that educates, reassures, and gently moves people forward.
A successful website does not force you to pick between informing and converting. It does both by understanding how people behave. Visitors come with questions, doubts, and expectations.
They form impressions in seconds, responding to layouts that feel simple, familiar, and trustworthy.
Credibility comes from clear design, transparency, and the ease of finding relevant information. People act when they feel confident, and trust often determines whether they engage.
By focusing on clarity, professional aesthetics, and intuitive navigation, you create a space where visitors feel at ease as they explore.
Sharing expertise openly and keeping information up to date builds authority. Guiding users with well structured paths and honest, persuasive messaging makes it easy for them to take the next step when they are ready.
When you design with human behaviour in mind, conversions happen naturally as a result of a thoughtful, trusted experience rather than a push.
2026-02-20 18:11:30
When we talk about scaling systems, the default thought is:
“How do we handle more requests?”
But the better question is:
“What happens when we receive more than we can handle?”
That’s where backpressure becomes important.
Not as a buzzword.
As a stability mechanism.
In any backend system, different components have different capacities.
That gap doesn’t disappear — it accumulates.
It turns into:
Eventually → failure.
Backpressure exists to prevent that.
At its core:
Backpressure is a flow-control mechanism in which the consumer controls how much data it receives from the producer.
Instead of:
Producer → pushes endlessly
Consumer → keeps accepting
We get:
Consumer → “Give me 100. I’ll ask again when ready.”
That simple shift changes system behaviour completely.
Yes, it’s formally defined in the Reactive Streams specification
and implemented in frameworks like:
But the idea applies even in regular Spring Boot applications.
Think about:
If incoming rate > processing rate, the excess work sits in memory.
That’s uncontrolled buffering.
Backpressure is about making that buffering intentional and bounded.
while(true) {
sendEvent();
}
Consumer side:
Queue keeps growing…
Memory increases…
Latency increases…
Nothing crashes immediately.
But performance degrades silently.
subscription.request(50);
Producer:
Send exactly 50.
Wait for next request.
The system becomes predictable.
And predictability is what makes systems reliable.
Backpressure is not about slowing down traffic.
It’s about aligning work with capacity.
If a service can process 2,000 requests per second,
it should not accept 10,000 and “hope for the best.”
That hope becomes technical debt.
If consumer speed < producer speed:
Smart systems:
That’s practical backpressure thinking.
If DB supports 2k writes/sec
but API accepts 8k writes/sec:
You don’t have a scaling problem.
You have a flow-control problem.
In Spring WebFlux, you can do:
Flux.range(1, 1_000_000)
.limitRate(100)
.subscribe();
It processes data in chunks instead of flooding the subscriber.
That’s backpressure applied.
Most systems don’t fail instantly.
They degrade first.
Scaling isn’t just about handling more.
It’s about knowing when to slow down.
Backpressure is simply this principle:
Never accept more work than you can process safely.
And once you start thinking that way, you design systems differently.
More stable.
More predictable.
And far less fragile under pressure.
2026-02-20 18:07:15
Ever wonder how the "Great Sea" from Wind Waker suddenly got all spooky and cursed? Turns out, it's all thanks to some clever musical tricks!
The eerie vibe is created by throwing in tritones, clashing harmonies, and even nodding to Ganondorf's creepy theme. It effectively twists that adventurous sailing tune into something totally terrifying!
Watch on YouTube