Interview with Arkadiusz Gryczka, Senior Developer at Bright IT

IT and web development are constantly evolving and becoming more powerful. Experienced developers have seen the landscape change and learned new ways to test, analyze and implement new tools to deliver robust front and back end IT services.   

The last years have seen an industry-wide trend towards Microservices and Headless architecture and many developers moving away from monolithic architectures. Other structures such as API-first, GraphQL, and AWS (Amazon Web Services) have also been adopted to make total management easier and more efficient for developers. 

Arkadiusz Gryczka, Senior Developer at Bright IT, has been developing for over fifteen years and has seen many transformations throughout his career. We had the opportunity to sit down with him and discuss the future of IT services, how the industry has evolved and adapted, and his thoughts on current IT trends.


What are some of the programming languages you're using these days, and what is your preferred language?

Arkadiusz Gryczka: Great question and this also highlights how the industry landscape has evolved over the late decade or two. Before starting at Bright IT, my primary programming language was Java and Java EE (Enterprise Edition) in conjunction with their specifications, especially EJB, JPA, and JSF. When I joined the Bright IT team, I began an adventure with a completely new language, a welcome challenge. Though I was still running the Java ecosystem or even just JVM, by which I mean SCALA. This language was initially limited to academic use, but it became a powerful alternative to other "lengthy" Java languages for business applications. SCALA is an interesting language because you can be more succinct, and the code can be integrated and run as a Java EE application which increases efficiency and reduces redundancy. Another benefit of SCALA is that it offers many "lighter" solutions and frameworks that simplify development, providing necessary abstractions and standardizing work within many different classes of problems. So, I guess the short answer to your question would be that I prefer working in SCALA.

What are some of the tools you use most frequently?

AG: Like most developers, my primary tool is IDE or integrated development environment. Then typically, the project dictates what I will utilize to deliver the best end product. For example, if I'm working with a database heavy project, it's helpful to have a UI that enhances visualization for the results of query searches. Of course, I typically also utilize a healthy dose of a web browser equipped with Google search.

What are some of your favorite aspects of being a developer?

AG: I have an analytical mind which is one of the reasons I chose to become a developer. Finding logical solutions to complex problems and implementing consistency is deeply gratifying and one of the developer's primary functions. Because IT is ever-evolving, I enjoy staying at the cutting edge and spending my time learning new skills and languages. Also, I love the flexibility this career has given me; as a developer, I can basically work from anywhere as long as I have access to the internet.

Is there anything you don't enjoy as a developer?

AG: Ha! Overall no, sometimes meetings can become redundant. People who aren't IT professionals often don't fully understand our roles or even what we do, so that can be frustrating, and I wouldn't say I like it when people either complain about our UI/UX (User Interface/User Experience) when they have no idea what they're talking about. That said, like any profession, it has its pros and cons, but for me, it's mostly pros.

How has the programming landscape changed since you started?

AG: The biggest change has been that many of the problems we faced when I started now have comprehensive solutions, and there are more standards in place as tech giants like Google, Amazon, and Facebook have established languages and have developed new frameworks that provide valuable web services. The development process itself has changed as well. When I started, every volume of documentation had to be approved by the client, but new AGILE rules allow you to alter requirements specifications completely. Additional project documentation is easier to keep current and work management tools like JIRA simplify the task management process. This combination allows you to assess potential threats earlier so you can react effectively.

During the last years there's been a trend from monolithic architectures to Headless and Microservices. Can you define the differences between those three approaches/architectures?

AG: Sure, a monolithic architecture contains an entire system on one application, and both frontend and backend work as a single server application. Generally speaking, there is no GUI (Graphical User Interface) in a headless system, so systems work together and communicate through an API. Microservices build the system as a loose set of collaborating services with synchronous or asynchronous communication.

Say you were describing these different approaches to a person with no technical understanding, what would you say?

AG: Say you and your friends start a small factory. You purchase the necessary tools, machines, and manufacturing equipment and everybody involved brings a different skill to the table. To save money, you decide to use these additional skills, so someone starts delivering, someone else does accounting, and another person handles sales. In that case, you've built a monolithic structure where if one person is absent, you cannot function at 100%.

Now, say this factory develops into a larger business, and you need to outsource your sales team to focus on daily operations. So you bring in a third-party accounting team, and you're not concerned with how they do their job, just that they deliver good service. This becomes a headless system where your cooperation is necessary but how their accounting firm is operated on its backend is of no concern to your factory's success or operation.

As the factory grows, you find yourself with specialized teams. Some work the production line; others handle delivery logistics. You have sales teams and managers for each department. You decide that the sales team doesn't need to know too much about the production line and vice versa; they function independently. So now, if one delivery driver is sick, your operations don't halt, and your sales team won't even know this happened. Everything functions independently so that smooth operation is guaranteed; this is now a microservices system.

Are monolithic systems becoming a thing of the past?

AG: I don't necessarily think so. There are many occasions where creating and maintaining a microservices system is unnecessary due to the project's scope. I think headless systems will become more popular, as well as the separation of frontend development.

Is there a "one-size-fits-all" approach?

AG: Architectures and technologies we use always rely on functional and non-functional requirements and require separate analysis. So there is no way to have a system that is tailored to every project because each project presents its specific problems, and identifying the best approach is at the core of what developers do.

How has the shift away from monolithic systems influenced your work?

AG: I've worked on projects utilizing numerous systems, and even in monolithic systems, you still use new approaches. So it's not always the system that influences the technology, but the most significant difference is in the architecture, where you need a talented DevOps team to handle it.

Along with the previously mentioned systems, can you outline some other newer examples?

AG: There's API First, an approach where the design and development of an Application Programming Interface are prepared before implementation. GraphQL is a powerful query language that standardizes the API and lets you query only relevant data. GraphQL API uses JSON as query and data formats and is more flexible compared to plain REST API. AWS - Amazon Web Services is an extensive set of cloud services, which allows you to build all kinds of systems without your own IT infrastructure. It lets you focus on the core of your business needs or solutions instead of fighting with well-known and defined issues concerning hardware resources or performance, backups, servers administration, etc.

How does all of this relate and fit into the bigger picture?

AG: These concepts were introduced to answer real-life problems as new approaches to software development evolved. None of them is a silver bullet, and every project is different, so IT solutions need to balance the clients' needs and provide the best system for their project. This is the developer's role in making the best choice, even if marketing disagrees.

Apart from new query languages, hosting opportunities, and development approaches, what are some other advancements?

AG: With recent advancements, new issues arise, and we're continually learning how to notice and address them effectively. I don't want to bore you with too many details, but we sometimes have to change our thinking about the system entirely as developers. For example, QCRS and Event Sourcing can be used by microservices to make them more scalable, but we have to be able to work with data from Read Models that aren't always up to date.

Conclusion

Both front and back end development and UI/UX have been transformed, and staying at the cutting edge is paramount for the web developers at Bright IT. The ability to automatically scale has been one of the most significant changes to IT development over the last decade, and these robust architectures help businesses of every size ensure seamless reliability and powerful performance.

Arkadiusz Gryczka recently took part in a project for Swarovski Optik which utilized a headless, serverless approach. This novel system is the next evolution for cloud-based systems and represents a sea change for UI/UX as well as front and back end development. In part two of our interview he demonstrates with the recent relaunch of the Swarovski Optik website the benefits and reasoning behind the system.