devopsy.kinsta.cloud

Tag: application development

  • OutSystems Acquires Ionic to Further Automate App Development

    OutSystems Acquires Ionic to Further Automate App Development

    OutSystems this week revealed it has acquired Ionic, a provider of an open source framework that provides developers with a higher level of abstraction for building and deploying mobile and desktop applications.

    OutSystems CTO Patrick Jean said Ionic will accelerate the company’s ongoing efforts to extend the reach of its platform for building low-code applications without developers having to worry about, for example, the screen size of the device an application is deployed on it because the framework automatically right-sizes it. Ionic, in effect, will provide an extension to the platform that OutSystems already uses to automate the building and deployment of low-code applications, he added.

    In addition to its namesake user interface (UI) framework for building mobile applications that can run on multiple platforms, the Ionic portfolio also includes a tool for natively deploying web applications, dubbed Capacitor, and a toolchain for building web component-based design systems, dubbed Stencil. Collectively, these tools are used today by more than five million developers.
    OutSystems plans to extend the capabilities of these tools to make it simpler to deploy applications on both mobile devices and desktop systems, said Jean. The overall goal is to reduce the cognitive load that developers currently carry when they need to build and deploy applications that run on multiple platforms, he added.

    That capability will prove critical as more individuals beyond professional developers become involved in building, deploying and updating applications, noted Jean. In fact, many of those developers are likely to be business people that only develop applications on a part-time basis, he added.

    The percentage of applications being built using low-code tools has increased dramatically. Professional developers have embraced these tools and platforms alongside so-called citizen developers that are using them to build applications, as well. As the backlog of applications that needs to be built steadily increases, low-code platforms have played a crucial role in enabling developers to keep pace with the demand for new applications.

    Less clear is the impact these low-code applications are having on DevOps workflows. On one hand, there are clearly more applications that need to be deployed than ever. At the same time, many of the DevOps and data modeling processes that once required, for example, a dedicated continuous integration/continuous delivery (CI/CD) platform are being embedded in the platforms provided by the vendors that create low-code tools.

    Regardless of how low-code applications are deployed, the one thing that is certain is the pace of digital business transformation is being greatly accelerated by these tools and platforms. DevOps teams will soon need to put guardrails in place that enable developers with a wide range of experience and skillsets to securely deploy and update applications.

    On the plus side, DevOps teams should also expect it to become easier to automate the delivery of low-code applications at levels of unprecedented scale. In fact, the issue going forward may not be whether IT can keep up with the needs of the business but whether the business can keep pace with the rate of innovation now being enabled.

  • Snowflake Makes Case for Building and Deploying Apps on Platform

    Snowflake Makes Case for Building and Deploying Apps on Platform

    During a Snowday 2022 event, Snowflake this week moved to make it simpler to build applications on top of its cloud platform for managing data in addition to enhancing the overall security of the platform.

    The company has made generally available Snowpark, a framework for building Java, Scala, SQL or Python applications. Snowflake also committed to making generally available in early 2023 an open source Streamlit framework for building Python applications that Snowflake acquired earlier this year.

    Snowflake also revealed it is adding observability tools to the platform to make it easier to build, test, debug, deploy and monitor data pipelines, including alerting tools (private preview), logging capabilities (private preview), event tracing (private preview), task graphs and history (public preview).

    Torsten Grabs, director of product management for Snowflake, said those capabilities will make it easier to alert DevOps teams to issues that might arise with applications deployed on the Snowflake platform.

    At the same time, Snowflake is also making it simpler to build data pipelines by making a Serverless Tasks capability generally available. In addition, the company is previewing a Schema Inference engine that makes it simpler to ingest data and a Dynamic Tables capability to declaratively manage data pipelines.

    Other capabilities being added to the platform include a public preview of a Query Acceleration Service to make additional compute resources available on demand. Snowflake has also improved query efficiency with join elimination in addition to providing search optimizations.

    There are also now cost optimization tools that enable IT teams to run a cost-benefit analysis of Snowflake services in addition to tools that make it easier to replicate data across multiple cloud computing environments running the Snowflake platform.

    IT teams can now also replicate Streams and Tasks via a capability in public preview that enables data pipelines to seamlessly work on secondary Snowflake accounts and configure failovers using a graphical tool that is available in private beta.

    Finally, Snowflake has also enhanced its cross-cloud Snowgrid Capability to make it easier to share both public and private listings of data in addition to applying tags to and searching masked data.

    The latest editions to the Snowflake platform come at a time when more organizations are starting to adopt DataOps best practices to manage data. Snowflake is now making a case for building and deploying applications on top of a platform that automates the management of the data pipelines used by applications to access data.

    It’s not clear to what degree the Snowflake platform will be employed to host applications, but the company is clearly betting the volume of data residing in its cloud platform will attract a wide range of application developers that, in turn, will need to be supported by DevOps teams.

    Of course, Snowflake is not the only provider of a data warehouse or data lake that has similar ambitions. Regardless of platform, however, the one thing that is clear is that a convergence of DevOps and DataOps workflows is now underway as IT organizations look to streamline the management of the massive amounts of data that now reside in the cloud.

  • CNCF Survey Predicts Growing Wasm Momentum

    CNCF Survey Predicts Growing Wasm Momentum

    A survey of 93 developers conducted by the Cloud Native Computing Foundation (CNCF) found more than a quarter (28%) are using WebAssembly (Wasm) in their cloud-native development projects, with another 36% planning to do so during the next six to 12 months.

    The survey, published this week, is effectively a straw poll that found 42% of respondents are developing or plan to develop server-side applications using Wasm, while 48% are combining or planning to combine server-side workloads with client-side applications.

    Originally developed five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now starting to be used to rapidly build lighter-weight applications that can be deployed on any server platform. The promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

    The survey found 70% of respondents viewed Wasm runtimes as a disruptive emerging technology. The primary programming languages used in association with Wasm are Rust (59%), Go (47%) and JavaScript (46%), the survey found.

    Nearly two-thirds (63%) said they are both porting new applications using Wasm and migrating existing workloads, compared to 37% who said they were creating new applications only. The primary reason cited for migrating workloads to Wasm was application portability (78%), better security (77%) and improved runtime performance (70%).

    Security ranks high because existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. Wasm code runs in a sandboxed environment that isolates execution environments in a way that eliminates the ability of malware to laterally move across an application environment.

    Target platforms for Wasm applications include serverless computing frameworks (63%), edge platforms (54%) and the web (52%), the survey found.

    The biggest barriers to adoption were tools (46%) and lack of standards (45%). Just over half (56%) of respondents said Wasm developer tools are missing features and are difficult to use. A full 81% said they would like to see vendors provide full-featured and stable Wasm tools and projects.

    Matt Butcher, CEO of Fermyon, a provider of a platform for building Wasm applications, said that while survey respondents most likely represented more advanced developers, it’s clear Wasm momentum is starting to build. Much like JavaScript before it, Wasm is about to jump from the client to server-side application environments, he noted.

    Less clear is whether Wasm represents the next era of cloud-native computing or is simply another type of software artifact that will be employed to build applications alongside other artifacts such as containers.

    Wasm isn’t necessarily going to replace existing approaches for building applications any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster. Existing serverless computing frameworks typically use containers that are much slower to start up than Wasm code running natively on a platform, which accounts for why developers are looking to embrace the format to improve overall application performance.

    One way or another, more Wasm code will soon be finding its way into DevOps pipelines. The issue is determining how to incorporate it alongside all the other code moving through those pipelines.

  • Making App Dev More Efficient

    Making App Dev More Efficient

    Applications of all kinds are continually popping up across various industries to help improve consumer customer experiences, provide entertainment, make certain tedious or error-prone tasks easier for workers and to help businesses improve their operations overall. In fact, there are over 5.4 million applications available across the Apple App and Google Play stores as of this year.

    As more and more individuals and organizations turn to applications for various experiences and to drive enterprise efficiencies, we need to take stock of the process we deploy in application development.

    The Inefficiencies of Application Development

    Today, it is estimated that there are more than 26 million software developers worldwide. Each of these developers brings a unique combination of creativity and technology acumen to the organizations they work for and the applications they create. However, the current application development process in many enterprises is riddled with inefficiencies that often require these talented developers to focus on tedious, mundane, non-innovation-related tasks. 

    Technical Debt: Renowned programmer Ward Cunningham first introduced the concept of technical debt in 1992, stating, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” What many didn’t realize at the time was that technical debt would grow to be a major issue in software and application development years later. Recently, a new Scandinavian study found that developers dedicate 23% of their time, on average, to addressing technical debt. While this statistic alone should be alarming to enterprises—given their development teams are spending a quarter of their time on an issue that could have been avoided had a different approach been taken—the study also found that developers often have to introduce new technical debt in the process. 

    Maintenance: As with all technological equipment, applications require routine maintenance to ensure they remain working for the end user, provide ongoing value and are secure. However, unlike a car or kitchen appliance, applications see far more frequent updates from operating systems (OSes), cloud or hardware providers that need to be addressed by development teams. According to research from Stripe, developers spend more than 17 hours per week on maintenance issues like debugging or refactoring. For instance, take a look at Apple. From the time iOS 15 was released in June 2021 as a beta, there were more than a dozen updates made to the OS until early September 2022. That means that every single time the updates were released, developers had to spend time ensuring their applications were working correctly, were bug-free or complied with new security measures. When you add this to the fact that the average enterprise app has 110 third-party integrations, that is an extreme amount of maintenance.  

    The Reinvention of the Wheel: Of all the applications available today, many of them consist of the same foundational features and functionality—login, chat, social sharing, payments and more. What’s astonishing about this is that developers are frequently recreating each of these common features and functionalities from scratch every time they develop a new application. 

    It is clear that these tasks are highly inefficient, and it begs the question, “What can be done to address these inefficiencies?” 

    Prioritizing Innovation 

    It is not enough to just introduce some sort of technology in the hopes that it makes application development more efficient. It also requires an overall mindset change by enterprises. Yes, it is still of the utmost importance to get applications to market quickly and keep up with the pace of competition; however, innovation doesn’t have to be sacrificed to do so. 

    Innovation must be the key driver for enterprises and their development teams. Providing unique value and experiences to end users will truly set enterprises and their applications apart from the competition. But, the reality is that nearly 80% of technology leaders from around the world believe basic application maintenance and support are the biggest barriers to innovation. 

    Enterprises must be able to balance innovation, time-to-market and development processes that are free of technical debt and outrageous maintenance support. 

    Making Application Development More Efficient

    One way in which enterprises can balance innovation, commercialization, and development is through an emerging approach to application development known as features-as-a-service (FaaS). 

    A FaaS approach to application development enables enterprises to implement an agile and accelerated engineering process—similar to that of low-code/no-code without the constraints often seen with those vendors and their functionality today—without sacrificing quality, code or time. More specifically, it combines pre-coded “commodity” features with continuous and automatic updates that empower development teams to spend their time and creative minds on innovation. In most cases, this approach can help enterprises bring applications to market within weeks instead of months and limits the headaches on the backend for development teams down the line. 

    As enterprises work through the fourth quarter of this year, I implore them to reconsider their development process at a fundamental level and bring innovation to the forefront before the beginning of 2023. Time and resources are of the essence, and something must be done now to address the inefficiencies of application development. 

  • Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Technologies this week launched a hosted platform-as-a-service (PaaS) environment, dubbed Fermyon Cloud, that promises to make it simpler to build WebAssembly (Wasm) applications.

    Announced during the Cloud Native Wasm Day event during the KubeCon + CloudNativeCon North America conference, Fermyon Cloud is now available in open beta.

    Fresh from raising $20 million in funding, Fermyon CEO Matt Butcher said IT teams can quickly build and deploy Wasm applications using a Fermyon Spin development tool and a Fermyon Platform the company launched earlier this year.

    Fermyon Cloud adds an opinionated PaaS environment managed by Fermyon that can start up Spin applications in less than a millisecond. It uses a serverless application programming interface (API) that makes it possible to cache and optimize applications as they are loaded, noted Butcher.

    Originally developed more than five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now used to rapidly build lighter-weight applications that can be deployed on any server platform. In effect, the promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

    Wasm isn’t necessarily going to replace existing approaches for building applications, at least not any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster.

    In addition, at a time when organizations are becoming more concerned about application security, the appeal of Wasm is clear. Existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. In contrast, Wasm code runs in a sandboxed environment that isolates execution environments to eliminate the ability of malware to laterally move across an application environment.

    Wasm is especially well-suited for building lightweight applications that previously might have been deployed on a serverless computing framework, noted Butcher. The issue developers are encountering when using a serverless computing framework is that those frameworks are based on containers that have comparatively slow startup times, he added.

    It remains to be seen how much traction Wasm gains in the months ahead, but Butcher said he expects most backend services, such as databases, will continue to be built using containers. Fermyon is betting, however, that many future cloud-native applications built by the average developer will be constructed using Wasm. In the longer term, Wasm will also soon be used to build applications infused with machine learning algorithms, said Butcher.

    In the meantime, DevOps teams should get ready for more Wasm code to move through continuous integration/continuous delivery (CI/CD) pipelines. The challenge, of course, is that code will need to be managed alongside all the other software artifacts moving through those pipelines, as well.

  • Three Ways to Speed up SAST

    Three Ways to Speed up SAST

    In modern, continuous software development life cycle (SDLC) processes, when code is written and before it’s committed to the repository, it’s run through testing, which may include unit testing, regression testing or static application security testing (SAST). The benefit of SAST for DevSecOps is the real-time feedback it provides developers as they create and make changes to the source code before they submit it. The amount of time that’s acceptable in this kind of workflow is 15 minutes to 30 minutes maximum, with some allowance for how big the change is. Fast feedback means quicker turnaround and more progress on features. The business value lies in those features. Testing makes sure they work.

    Depth Versus Breadth

    Checkers used by SAST are not all created equal, at least in terms of the computation power needed. The time for analysis is directly related to the complexity of the checkers used to detect certain types of vulnerabilities. Typically, coding standard enforcement rules are easier to compute versus complex tainted data analysis used to detect command or SQL injections, for example. Therefore, there is a trade-off to be made in the types of bugs and vulnerabilities being detected. When developers are coding, it makes sense to optimize the compute time for SAST to reduce any delays. During software builds, more time and compute power is available so depth and breadth can be increased to catch complex vulnerabilities.

    Compute Power

    SAST analysis time scales well with compute power. The availability of more computing resources such as CPU and memory, can impact the time of analysis. Bigger is better in this case and investing in additional hardware for SAST can pay off in terms of productivity.

    Codebase Size

    SAST analysis time is also dependent on the amount of source code analyzed. Depending on the application, the code base is a determining factor in terms of what depth and breadth of analysis is optimal.

    There is some correlation between small code base size and strict requirements for SAST such as in safety-critical software. It’s expensive to build and test safety-critical code, but code size is typically smaller than in other types of applications. However, these products need to conform to industrial coding standards and thus require rigorous levels of testing and analysis to detect a wide variety of defects.

    Larger and extremely large code bases require a trade-off in terms of depth and breadth of analysis. Prioritizing the types of defects and vulnerabilities to concentrate on is critical.

    Speeding up SAST means reducing the amount of work. The most intensive operation is a full analysis of the entire source code base. Just as full compilation from scratch takes a long time, the same is true of SAST analysis.

    To accelerate SAST processing times, follow the same three techniques used to avoid compilation in large C/C++ projects: incremental analysis, component analysis and developer analysis.

    1. Incremental Analysis

    Incremental builds are a major factor in reducing developer build times for C and C++ projects. Small changes don’t require the entire code base to be recompiled. It’s impractical and unnecessary. When a developer modifies something, only what’s needed to be recompiled gets recompiled automatically, and the build infrastructure handles it.

    SAST works in a similar manner. As source code is being compiled, SAST parses the same source code and creates a program model. The second phase is analyzing that program model against the configured checkers and generating warnings. The warnings typically go into a database for later analysis.

    During the build of the software, SAST is run in parallel. Although similar to a compiler in operation, SAST must do more work than the compiler and takes longer to finish and provide results. The amount of code needed to recompile for each change directly impacts analysis time.

    Meanwhile, SAST of an incremental build requires a lot more work than just analyzing the changes. SAST uses abstract execution of code flow through multiple different compilation units. So even though a single file is modified, the calls it makes to other files need to be analyzed as well. The incremental analysis doesn’t increase the build and parse workload, but the analysis scope will be a lot bigger than expected. So, whenever you do an incremental build, SAST will need to reanalyze the dependencies, changes and related bits and pieces around those changed units.

    Nevertheless, it remains a good option for reducing SAST analysis times.

    2. Component Analysis

    If the software being developed has a loosely coupled, component-based architecture with well-defined interfaces, it’s possible to isolate both the testing and the SAST analysis to the component where changes were made. Just as this type of architecture simplifies many aspects of development, it pays off with SAST as well. It’s possible to analyze the component in isolation and get good results.

    3. Developer Analysis

    To further reduce SAST workload, start the first build without SAST, which removes the burden of the extra computation needed. Since subsequent builds are a lot smaller and build speed is much faster.

    However, there is an increase in false negatives due to the smaller scope of analysis since only files that changed are analyzed. This smaller scope means that all possible dependencies are outside the program model and are not considered in the analysis. However, this rapid analysis works well with coding standard enforcement, for example.

    Developer SAST

    Where to Start?

    Begin with a full build and analysis. This sets a baseline for detected bugs and vulnerabilities and establishes a performance target for reducing build time. This step will determine the exact number of lines of code, how long the analysis takes and its impact on build server load. These metrics should drive the analysis optimization effort.

    Given the options, the first step should be a component-based analysis. If this works well, it’s still possible to further reduce analysis with incremental and developer analysis within components. This approach can be integrated into typical developer workflows.

    When creating a developer branch for implementing changes, quick developer local analysis will catch local errors. These tend to be the largest set since they represent the largest part of the code changes. When enforcing coding standards, this is the point where violations are identified. A full analysis is recommended on a merge request to detect remaining defects related to cross-component-boundary behavior.

    Speed up SAST

    To speed up SAST consider using these techniques at the appropriate development stage to reduce time to complete, while still producing excellent results. Keep in mind that:
    ● Complete analysis yields the best and most precise results,
    ● Incremental analysis only analyzes recompiled code that has been modified,
    ● Component analysis works well in software that follows a well-defined component architecture and
    ● Developer (local) analysis provides a good compromise of precision and analysis time.

  • Microservices Explained: Not Your Father’s SOA

    Microservices Explained: Not Your Father’s SOA

    Microservices are frequently referred to as a variant or derivative of service-oriented architecture (SOA), if not essentially the same thing. While there are similarities and both are designed around the concept of services, that’s where the similarities end. Each was created around a different set of principles and intended to address different problems.

    Microservices architecture is built around key concepts that, when applied, not only differentiate it from other architectures but deliver advantages that accelerate software delivery and help to scale large, complex applications. To deliver on the promise of cloud-native, microservices must be loosely coupled so that, ultimately, they are independently deployable. Any microservice can be updated and deployed—just that containerized microservice—without requiring changes to other microservice(s). Loosely coupled microservices mean they are not sharing databases or maintaining state, for example.

    How big should a microservice be? Or, in other words, how much should it do? The answers range from ‘a single thing’ to ‘a small set of related code with high cohesion’. Another factor is that getting too granular can overrun a microservices-based application with large numbers of microservices, increasing complexity and making triage through observability and tracing very challenging.

    Scaling microservices-based apps is another important factor. Autonomous microservices can be replicated and scaled for performance and workload using container orchestration tools such as Kubernetes.

    Microservice communications are achieved through well-thought-out APIs created around the business or operational capabilities the microservice provides to anyone or anything engaging through the API. The API, and data provided through the API, are often referred to as ‘technology-independent.’ It’s probably better stated that microservice APIs are built using approaches like RESTful and GraphQL over networks that are not tied to any one specific operating environment, technology or programming language. JSON, YAML and XML similarly represent data that is transferable across technologies.

    The following diagram of a media application demonstrates the principles of microservices architecture. Microservices for scheduling media, digital rights management, tracking impressions and adding new ad insertions are loosely coupled, autonomous and have well-defined API interfaces. Each microservice can be changed, enhanced and deployed rapidly and independently of other microservices.
    Microservices SOA

    Service-oriented Architecture, or SOA, emerged to solve a very different problem; the overwhelming size and complexity of monolithic applications. Monolithic applications have very large codebases that often don’t do a good job of compartmentalizing functional or business logic. This makes changes to the codebase challenging even to developers who know much of the codebase well.

    Services in SOA were often used to gather a collection of similar business logic together and then share them as a service with other parts of the application, as needed. Technologies like message buses are used to make requests of a service and operate as traffic managers for requests across multiple services and other parts of the application. While reusability was a critical design consideration, SOA services were still quite large, and deploying services at high velocity was not an important design consideration. SOA services often take considerable time to code and test the service including interdependencies across other parts of the application before deploying as part of a larger software release.

    One important note: There are benefits and drawbacks to microservices and SOA architectures; neither is ‘better’ than the other. Which architecture to use when mainly depends on the purpose of the application you are building. For larger, more complex enterprise application environments that require integration with many other applications, you might choose SOA. That’s a better fit than for smaller applications that don’t require middleware elements for managing the requests within the app or between other applications. Microservices, on the other hand, are better-suited for smaller and well-partitioned web-based systems. They are becoming the standard for today’s cloud-native applications, and also are a great fit for developing a mobile or web application because they give developers more control.

  • Low-Code/No-Code Options Key to Bringing Web3 Mainstream

    Low-Code/No-Code Options Key to Bringing Web3 Mainstream

    Driven by cryptocurrencies and NFTs, Web3 is one of the most talked about technology industry waves in the last several years. But even with all the money it’s generated and the media coverage received, Web3 hasn’t yet gained the mainstream acceptance that Web2 has achieved. One of the main reasons for this gap is that blockchain-based technology continues to be complex, requiring developers to learn new languages and development environments as well as gain expertise in concepts like cryptography, hashing, oracles, zero-knowledge proofs, proof of work, proof of stake and more. And even once users understand that they then need to figure out how these pieces all fit together. The required time and money investment has slowed adoption by developers—until now.  

    Web3 is finally coming into its own, thanks in part to the abstraction provided by SDKs and APIs. This technology is making it increasingly possible for all developers, not just Web3 developers, to participate and innovate on this new wave of technology disruption.

    If you look at many of the providers in Web3 like Infura (ConsenSys), NFT Port and OpenSea, for example, and their growth, there’s been a significant movement from these providers over the past couple of years from simply providing nodes for underlying blockchains to now offering higher-level APIs. This translates into developers and companies no longer having to set up their own nodes to provide SDKs and higher-level APIs that rely on data indexers and pre-audited smart contracts to simplify token minting and reading from blockchains. 

    With the evolution of APIs and SDKs, developers using these programs no longer have to learn the intricacies of creating contracts on different blockchains, multiple developer tools, syntax and languages nor must they possess a deep understanding of these different blockchains. Instead, developers can rely on APIs that abstract the underlying complexity, easing the burden for developers who need only pass parameters like chain for indexing, token or smart contract IDs and other general-purpose information. These APIs will evolve into providing more low-code/no-code offerings with larger graphical UI components that developers can simply drag-and-drop to extract value as well as create DApps that can also be retrofitted into their existing applications or app infrastructure. 

    This evolution will be similar to the way the cloud evolved; look at AWS’ and Azure’s infrastructure-as-a-service (IaaS) as a current example. Existing apps could be lifted and shifted onto the cloud. This led to platform-as-a-service (PaaS) offerings with APIs that were cloud-ready; with developers’ latency, security and scalability needs augmented by low-code or no-code offerings. This is also similar to Microsoft’s Power Platform which used drag-and-drop operations on many cloud components, allowing integration and extensibility of the Microsoft platform in a short amount of time. This spawned a new generation of ecosystem players as the bar to participate and innovate in the cloud lowered; now every type of developer, no matter what their area of expertise, can take advantage. This also meant that the new technology was accessible for all developers to solve business challenges more quickly while significantly decreasing time-to-market.  

    You can already see this parallel in the Web3 world. A lot of the key players building developer tools are starting to target the business and technical decision-makers. They are talking about how easy it would be for Web2 developers to leverage their high-level APIs and SDKs (something that Web2 developers understand extremely well) to use Web3 technology to solve new business challenges. And they can do so without setting up expensive innovation organizations and looking for scarce (and expensive) Web3 developers. The next step in this evolution would be to extend these APIs for NFTs, analytics, streaming, MEVs, estimating gas and more to have no-code, automatically generated components that finally allow more Web2 developers to transition to Web3 and, as a result, bring Web3 into the mainstream.

  • Getting Started With GraphQL APIs

    Getting Started With GraphQL APIs

    GraphQL, a query language for APIs and a runtime for fulfilling those queries with your existing data, is rapidly growing in popularity. According to the latest State of JavaScript survey report, 44.3% of respondents said they had used GraphQL APIs in 2020 compared to only 5% in 2016. Additionally, many Fortune 500 companies now use GraphQL APIs for their backends in production, while top tech companies like Facebook and GitHub use the API technology to improve their product offerings and boost system performance.

    With the ever-changing technology landscape, you might have doubts about adopting GraphQL API for your backend and be unsure how it can improve your current data needs. However, regardless of what language or architecture you are using, GraphQL APIs can help simplify data access, supercharge the product development process, improve application performance and handle complex back-end data scenarios.

    One Unified Endpoint For Your Backend

    One advantage of GraphQL APIs is that they provide a single unified endpoint for your backend to meet both client and general API use cases. A single GraphQL API can handle all the client’s requests and forward them to the correct backend service.

    As companies and their products scale, REST endpoints can become large and incredibly hard to manage. One of the main problems in REST is the N+1 problem, where the client calls the server N+1 times to get N number of resources, mainly because a single REST resource does not provide enough information for the client to operate with.

    Brennan Saeta, an infrastructure engineer at Coursera, cited centralizing REST APIs for simple consumption by the client as one of the reasons why GraphQL API appealed to them.

    GraphQL API hides the complexity of the underlying backend system by aggregating the required data from different sources and providing a simple interface that clients can communicate with through a single resource.

    Improved Application Performance With GraphQL

    GraphQL API improves application performance by reducing JSON payload size and network overhead from multiple API calls. By allowing the client to specify its data requirements, GraphQL APIs eliminate the need for unnecessary generic data being passed from the back end and minimize the number of roundtrips required to retrieve back-end data.

    As companies scale and iterate their products, the data required by different clients and pages changes. In REST API design, when new requirements arise, developers must decide whether to create a new endpoint and have clients make a new request for that data or add more data to an existing endpoint. The first option leads to more server roundtrips, and the second option increases payload size, which can hinder app performance.

    With more applications being accessed over flaky mobile networks and app speed being an important metric for retaining users, minimizing server roundtrips and data transferred over the wire is paramount. Companies like Netflix and Pulley have reported faster page load times and overall app performance after switching to GraphQL APIs.

    With GraphQL APIs, clients receive only the data they specify from the backend server in a single trip, saving network bandwidth and resources.

    Improved System Reliability

    GraphQL API improves system reliability by ensuring that client queries are valid and in sync with the GraphQL schema specification before query execution. GraphQL uses a type system that describes what type of data can be queried from the backend server and in what form it exists. A strongly-typed schema offers enhanced security over REST APIs by preventing breaches like SQL injection and unintentional data leaks, resulting in a more secure and reliable application.

    Type-safety ensures that any breaking changes by the backend server would be caught by clients consuming the data, resulting in less downtime. With GraphQL APIs, you can modify and deprecate API fields while still maintaining backward compatibility. It is easier to know which fields in the API are being used by what clients and which ones are not. With GraphQL, API developers can confidently make changes to the existing APIs without breaking the existing functionality.

    Swiggy, India’s largest food delivery platform, discussed how adopting GraphQL API for their back end enabled them to make changes to their existing APIs without breaking the consumer application.

    GraphQL ensures API consistency, reliability and security, resulting in better system performance.

    Better Developer Experience

    Adopting GraphQL APIs improves the developer experience for both frontend and backend developers. Backend developers want to build APIs that are intuitive and easy to explore and navigate. GraphQL helps with that by reducing the time spent documenting APIs.

    Through a concept known as introspection, GraphQL APIs allow clients to query the schema and discover the resources available on it. With excellent tools and libraries like the GraphiQL IDE, the interactivity for GraphQL API endpoints is much more intuitive for the developer.

    API consumers want APIs that are flexible, easy to integrate and support a variety of client use cases (web, iOS and Android). Because of REST’s inflexibility, it is challenging to create a single endpoint that can meet all of the client’s data requirements. Often the same client has to call multiple APIs to get the data it needs from the backend. Additionally, with REST APIs, frontend developers have to rely on the backend for API specifications before building product features, leading to slower development time.

    Peter Downs, director of engineering at fintech startup Pipe, said choosing GraphQL APIs early on cut their development time by 90%. With GraphQL APIs, frontend and UI developers can quickly and easily iterate on features by simply specifying the data requirements in the GraphQL API, thereby reducing the dependence on backend developers to make changes.

    Getting Started With GraphQL APIs

    The best way to learn GraphQL is by getting your hands dirty and building applications with it. Depending on your language of choice, there are GraphQL libraries in many different languages to help you get started.

    As with any new technology, adopting GraphQL APIs for your back end and building high-performant GraphQL backends requires experience, which is not peculiar to GraphQL alone.

    If your application relies heavily on interconnected data, you aim to develop an API to be used across several clients or are looking for a high-performant API solution for your backend that minimizes bandwidth usage, then GraphQL API is a perfect data layer for your backend.

  • GitHub Adds Tools to Simplify Management of Software Development

    GitHub Adds Tools to Simplify Management of Software Development

    GitHub has made generally available Projects powered by GitHub Issues, a set of tools for managing application development projects based on a spreadsheet interface.

    Mario Rodriguez, vice president of product management at GitHub, said these tools enable DevOps teams to more easily filter, sort and group issues and pull requests. That capability makes it possible to, for example, configure and track cycle velocity and current work status and create visualizations using cumulative flow diagrams.

    Over the course of the rest of this year, Rodriguez said GitHub also plans to add additional capabilities including custom triggers, conditionals and action logic along with a mobile edition of Projects powered by GitHub Issues.

    The overall goal is to provide DevOps teams with a set of project management tools that enable organizations to plan where they code, said Rodriguez. In many cases, that approach eliminates the need to deploy a separate set of project management applications, he added.

    As more organizations become dependent on software to drive digital business processes, it’s become apparent that managing all the ongoing application development projects has become a significant challenge. GitHub has been developing Projects powered by GitHub Issues to provide organizations with a set of tools that can be accessed not just by DevOps teams but also by application owners and business leaders to track the status of various projects, said Rodriguez.

    Most organizations have not reached the point where revenue growth is completely dependent on the rate at which software is developed and deployed, he noted. However, as DevOps teams more regularly engage other departments in the business, Projects powered by GitHub Issues can provide anyone with access to a spreadsheet-like application that is simple to use, said Rodriguez.

    In general, GitHub is committed to improving developer experiences at a time when organizations are competing for the best talent available, added Rodriguez. If salary and benefits are equal, the decision to work for one company versus another comes down to the quality of the application development experience, he noted.

    As the provider of the most widely-used code repository, GitHub has been extending the reach and capabilities of its platform to address a range of DevOps workflow issues. The issue that DevOps teams need to address is how to anchor those workflows to a code repository versus the continuous integration/continuous delivery (CI/CD) platforms they employ to build and deploy applications.

    Regardless of approach, there’s no doubt that DevOps teams can now construct more scalable workflows. That’s critical, because the number of concurrent application development initiatives that organizations are managing simultaneously has increased substantially in recent years. The underlying platforms used to manage those projects need to be extensible to prevent workflows from becoming overly rigid, said Rodriguez.

    It’s not clear to what degree business leaders appreciate the value of DevOps workflows, but as business processes continue to evolve, the ability to effectively compete could rest on the agility of an application development team.