When I was a junior developer I always wanted to find new and complex ways to do things. There was a strong urge to follow the path of most resistance because it seemed to be the ‘coolest’ way to do something. At this stage, a very wise and tired senior developer told me this: ‘In your career, you are going to write 1000 processes that import a file, at some point, you will realise that seniority is not about the coolest way to do things, but the easiest and most efficient way.’ This conversation always echos through my mind, how can I make things easier?
This is why low-code is so appealing to me, it allows users to create applications much faster than pro-code. Not to say that pro-code is bad in any way, but if I only have an hour to create a process that will import a file, test it, and get it to UAT by the close of business, low-code tools are a no-brainer. (I did an article on the viability of Low-Code for developers if you want to read more)
Creating a File Reader with low-code
In a recent post, I explored just this very rudimentary task that will be done by most, if not all, IT departments: Importing a file and making the data available elsewhere. I decided I wanted to make the data available via REST API.
By using my low-code tool of choice, Linx, I was able to develop this very simple process in less than 15 minutes. Another 30 minutes and I could add in logging, and error handling and add a layer of polish. I suppose time will have to be allocated to testing and deployment as well, but you get the idea, we are saving quite a substantial amount of time.
Understanding what you are getting into
Many like to point out that low-code has many pitfalls and limitations, and that it will never truly replace pro-code or conventional coding tools. I agree with this sentiment, it's hard to think of a world without pro code. There are too many bespoke systems and specific problems that need solving. That said, we can utilize these tools to optimize some of the more ‘ordinary’ development tasks such as loading a file.
That said, we need to be very careful in picking a low code tool, it needs to fulfil our needs and we need to ensure that it does not lock us into its own environment when we need to have freedom.
What I am trying to say is that you need to choose a platform that will meet your (and your organisational) requirements and needs.
The right tool for the job
When choosing a low-code tool, make sure that you are choosing the right tool for the job. Ensure that you are not choosing a front-end tool to do back-end tasks. It might work, but why do we want to use a spoon when we need to use a ladle. For back-end applications, I like to use Linx. Not just because I am employed by the company that makes Linx, but also because I have seen it in action. I have seen it used to create intricate back-end systems in massive enterprise environments.
If you are interested in reading more about how I created the above-mentioned process so quickly, feel free to read the post here. There is also a YouTube video that has all the steps.
Top comments (0)