It’s a new year and people are re-inventing themselves with their new year resolutions. We can apply this same concept to other aspects of our days, such as the way we integrate systems! Here are five things that you should start (or stop) doing when it comes to data integration in 2020.
#1 Automate your unit tests
There’s nothing more fun for a developer or architect than getting a new project and starting to code that assignment. Once you’re done and your code operates exactly as you expected, you migrate it to the next level environment, and suddenly it starts failing. Why would the code work in one environment and not the other? Your peer finds that you hard-coded some environment-specific variables into your code, causing it to break after migrating. Now you feel like a dummy, because something so simple broke your code… but how could you have prevented that from happening? The answer is automated unit testing.
I know, I know… testing code is the most boring part of our job, but it’s also one of the most important parts. Luckily, MuleSoft makes that boring part easier with MUnit. MUnit is a Mule application testing framework that allows you to easily build automated tests for your integrations and APIs. This means that so long as you build out the MUnit framework as you build units of code, you can automatically test your code as part of your CI/CD pipeline when you migrate it to different environments.
#2 Don’t skip performance testing
Most people hear the words performance testing and they think, “I don’t need that, my application is going to be very small won’t be used by many people.” But that couldn’t be further from the truth. Before going into production, every application should undergo some form of performance testing. Performance testing ensures that applications can withstand day-to-day, wear and tear, in addition to handling unexpected bursts in activity or abnormally large workloads.
There are several types of performance testing strategies that can be performed during the non-functional testing phase of development, depending on the readiness of the system. Below are some (not all) examples of types of performance tests and their benefits:
Load testing: Measures the system performance as the workload (either concurrent users or transactions) increases.
- Helps you understand the application response time as staying power of an application as loads increase.
Stress testing: Measures the system performance when the number of users or transactions are well beyond normal working parameters.
- Helps you understand what the breaking point of your application is. How many users or transactions does it take to cause your application to fail?
Spike testing: A form of stress testing that measures system performance when the workload suddenly increases quickly.
- Helps you understand how your applications will perform when there is a sudden surge in activity from a user or transaction volume perspective.
Endurance (soak) testing: Measures the system performance, at a normal workload, over an extended amount of time.
- Helps you ensure that the underlying systems of your application are working properly and you don’t have things like memory leaks occurring that could cripple and application in production.
#3 Gather non-functional requirements
Project stakeholders are often great at articulating what they want an application to do when a project is initiated. For example: “Give me the ability to search for people I work with” or “I want to edit a lead in Salesforce.” As integration developers and architects, are great at delivering those things to the stakeholder. But, how good is that search application if it takes an hour to return results or that lead creation app allows anyone to edit the lead information? This is where the importance of non-functional requirements come in.
Functional requirements describe the “what” of an application, but non-functional requirements describe the “how.” Both are equally important, but non-functional requirements often get forgotten about. It is just as important to understand the functionality of an application as it is to understand how an application should function. Below is a non-exhaustive list of non functional requirements that are important to gather:
- Performance: What should the response time of your application be? How many users will be using the application concurrently? What should throughput look like?
- Availability: Does this application need to be HA? Does it need disaster recovery?
- Security: Who has access to the application? How will the application know who is accessing it? What authority does that user have?
- Scalability: What happens when the application reaches its breaking point? How should the application grow? Autoscaling?
#4 Develop an error-handling strategy
When an error comes up during development, most developers need to decide whether they’re going to try to figure out or let someone else handle the issue. What if you could simply call a framework that did all that decision making for you? This is where an error-handling strategy (and subsequent framework) comes into play… you simply pass the error and some context of the error onto the framework and it will decide if a support ticket needs to be made, if it should retry the transaction, or ignore it all together.
A comprehensive error-handling strategy is critical to any successful organization because it ensures that errors are handled in a standardized way across all applications and takes the work off the developers and into a reusable process.
Some things to consider when you develop an error handling strategy are:
- What type of error is it? Is it a transient error that can be retried and might fix itself (i.e. some kind of network error)? Or is it a poisoned message that won’t fix itself no matter how many times you retry it (i.e. a authentication error)?
- How critical is the error?
- If the error is transient, how many times should you retry it before you give up?
- If you can’t resolve the issue, what do you do then?
- Who should be notified (and how) when an error occurs?
#5 Publish assets to exchange
I used to work with an architect that once told me, “That’s amazing work! You should have never done it.” At first, I was confused, why would he say that? Then he explained that had I spent a short amount of time to discover that s the work I did had already been done, which could have saved time and money on that project that could’ve been spent on other value-add work. But this leads to another question, how would I have known if someone had already done this work?
Luckily, MuleSoft has Anypoint Exchange, which provides you the benefit of discovering, sharing, and incorporating assets and resources into your applications. Additionally, it helps you create API developer portals, view and test APIs, simulate data to APIs (Mocking Service), create assets, and use API Notebooks to describe and test API functions.
If every developer were to publish documentation for every project they’ve worked on in Exchange… and subsequently looked in Exchange prior to beginning development for assets they can re-use, so many people would save so much time and money on their work.
Where do I start?
Many people make New Year’s resolutions, without meeting them, because their goals are too lofty or they take on too much at once. The same will happen if you go gung-ho on this list and try and implement everything all at once. So start slow.
First, figure out what is most important to your organization and educate yourself on the topic. Perhaps your organization is in dire need of an error-handling strategy… check out this entry level blog to start. Maybe you need to level-up on your unit testing? Check out the awesome documentation MuleSoft has for MUnit on the documentation site. Whatever is most important to you, start with educating yourself on that topic.
From there, implement some of what you learned in your next project and continue to build upon what you’ve done with each subsequent project. Once you feel comfortable with one topic, move to educating yourself on the next. Before you know it, you will be on a whole new level with your integration and ready to make a brand new set of integration resolutions for 2021!
