Extending CloudFormation and CDK with Third-Party Extensions

Did you know you can use CloudFormation to manage third-party resources? The AWS CloudFormation Public Registry provides a searchable collection of CloudFormation extensions and makes it easy to discover and provision them in CloudFormation templates and AWS Cloud Development Kit (CDK) applications. In the past three months, we’ve added a number of new, exciting partners to the Public Registry, including GitLab, Okta, and PagerDuty.

The extensions available on the registry are wide-ranging and include third-party resources from partners such as MongoDB; hooks, which are preventative controls that add safeguards to provisioning; and modules, which are re-usable components that take into account best practices and opinionated definitions of resources. AWS Partner Network (APN), third parties, and the developer community contribute these extensions to the Public Registry. Using extensions, customers no longer need to create and maintain custom provisioning logic for resource types from third-party vendors.

Over last few months, AWS collaborated with partners to develop and publish over 80 new resources across 14 providers to Public Registry for CloudFormation. Below is a summary of the new resource type additions.

Recently Updated Third-Party Providers

Provider
Use case

MongoDB Atlas

Manage components in MongoDB Atlas. Add, edit, or delete administrative objects within Atlas, including projects, users, and database deployments

Note: You cannot read or write data to Atlas Clusters with Atlas Admin APIs and AWS CloudFormation resources. To read and write data in Atlas, you must use the Atlas Data API

GitLab
Manage the users and groups in an organization, set up a new project with the right users, groups, and access token, tag a project automatically for every active CI/CD deployment

New Relic
Create a new Dashboard with custom Pages, Widgets and Layout, add tags to your data to help improve data organization and findability, workloads-related tasks

GitHub
Manage the users and groups in an organization, set up a new project with the right users, groups, and access token, Add a webhook to a repo

Dynatrace
Set up a new project with service level objective, locations, monitors and metrics

Okta
Onboard a new application into Okta with the right users and groups

PagerDuty
Set up monitoring of a new or existing application

Databricks
Set up a Databricks cluster and jobs

Fastly
Configure Fastly as a CDN for your web app

BigID
Connect S3 and DynamoDB data sources into your BigID application

Rollbar
Set up a new Rollbar project and manage rules, teams, and users

Cloudflare
Configure a DNS record and load-balancing using Cloudflare

Lacework
Configure Lacework alert profiles, rules, channels and manage queries

Snowflake
Create databases, users, and manage privileges

Key Benefits

Here are some of the benefits for extension builders and consumers when publishing extensions to the public registry:

Discoverability – Publishing your extensions in the public registry will make them discoverable by 1M+ active CloudFormation and CDK customers.

CDK Support – We’re seeing rapid growth in the adoption of the CDK amongst the developer population. Upon publishing to the registry, L1 CDK Constructs will automatically be created for your third party resources making them compatible with the CDK with no added work required. These constructs will also be listed on Construct Hub and aids discoverability discoverable by customers. Note: Automated L1 CDK construct generation is currently an experimental feature.

Drift detection – Third-party resource types in the public registry also integrate with drift detection. After creating a resource from a third-party resource type, CloudFormation will detect changes to the third-party resource from its template configuration, known as configuration drift, just as it would with AWS resources.

AWS Config – You can also use AWS Config to manage compliance for third-party resources consumed from the registry. The resource types are automatically tracked as Configuration Items when you have configured AWS Config to record them, and used CloudFormation to create, update, and delete them. Whether the resource types you use are third-party or AWS resources, you can view configuration history for them, in addition to being able to write AWS Config rules to verify configuration best practices.

Abstraction of Best Practices with Modules – Browse and use modules from the registry when creating your CloudFormation templates to ensure you’re provisioning resources while adhering to best practices.

AWS Cloud Control API – The AWS Cloud Control API allows AWS partners and customers to interface with your resource type through API calls using Create, Read, Update, Delete, and List (CRUD-L) operations. Resources in the registry will be automatically integrated with our AWS Cloud Control API and expands your third party resource compatibility to even more AWS services and IaC tools.

We’ve seen great momentum from our partners and developer community over the past year. We are looking forward to continued investment and innovation in the Public Registry.

How to Get Started

For Resource Type Users: Explore and Activate Third Party Resource Types

Third party resource types must first be activated before they can be used. You do this by logging into your AWS Console > Navigate to CloudFormation > Registry > Public extensions > Set the Publisher to Third Party. This will show you a list of available third-party resources in your region (note that different regions may have a different set of third-party resource types). Select the radio box next to the resource types you want to activate and click the activate button at the top of the list.

Figure 1:

Don’t see the extension you need in the registry?

You can submit requests for new third-party extensions through our Community Registry Extensions Github repo issue tracker! Click the New Issue button and describe the third-party extension along with information about your use case.

For Developers and Publishers: Join the CloudFormation Developer Community and Start Building

You can see several of the community-built registry extensions in the AWS CloudFormation Community Registry Extensions repository and even contribute yourself. You can also read about the experiences and lessons learned from publishing to the Registry through this blog written by Cloudsoft.

For developers looking to create new resource types to add to the public Registry, follow this creating resource types walkthrough help you get started. If you need assistance creating, publishing resources, or just want to join the discussion, you can join the conversation today in our CloudFormation Discord Channel. We’d love to hear about your experiences and use cases in developing innovations with registry extensions.

About the authors:

Anuj Sharma

Anuj Sharma is a Sr Container Partner Solution Architect with Amazon Web Services. He works with ISV partners and drives Partner-AWS product development and integrations.

Lucas Chen

Lucas is a Senior Product Manager at Amazon Web Services. He leads the CloudFormation Registry and its integrations with third-party products. Prior to AWS, he spent 9 years at VMware working on its end user computing product, Workspace ONE.

Rahul Sharma

Rahul is a Senior Product Manager-Technical at Amazon Web Services with over two years of product management spanning AWS CloudFormation and AWS Cloud Control API.

Is React a Framework? Software Engineer Answering

By definition – React is one of the most popular JavaScript UI libraries nowadays. It comes in second place after jQuery among all web frameworks! React’s popularity has grown rapidly thanks to a simple and declarative API that allows you to build high-performance applications, and that momentum keeps growing. Still, there is often discussion and questioning that React is a framework or library.

Firstly, let’s look what the differents between framework and library? 

The framework belongs to the main() function. It executes some functions, e.g. controlling a collection of windows on the screen. The framework can, in principle, work even if you have not set it up in any way. It does something, e.g. it places an empty window with default widgets. The framework defines the general nature of the program, and your code provides a specific setting. These settings can be very significant, as both a word processor and a spreadsheet can be created using the same framework.

The library is the set of tools used by your code. Your code belongs to the main() and provides the overall structure of the program. A library performs some specific task, such as sending traffic over a network, drawing charts, or something else. The library can do big things, like draw a view of a three-dimensional space full of objects, but only after you tell it about those objects.

The framework can call your code, which in turn calls the library. But your code never calls the framework, except perhaps for system() or exec() functions.

But, is React a Framework? 

We asked our Software Engineers Team for their opinion and they were split into two parts: some maintain the view that React is a library, and others assign it as a Framework. Here are the most outstanding opinions:

From my point of view, React is not a framework, it’s just a library with no specific requirements for project structure. It’s about describing the abstractions of your application, logic, routing, data exchange, and so on. And React simplifies the work with this data, and optimizes the work with it

Anton M. – Software Engineer at Flatlogic.com

From my point of view, React is not a framework, it’s just a library with no specific requirements for project structure. It’s about describing the abstractions of your application, logic, routing, data exchange, and so on. And React simplifies the work with this data, and optimizes the work with it

I know that react calls itself a “library”, and a lot of developers prefer to react to the home page with the title “library”. However, I think that React is more like a framework now, with different targets like web, react native, etc. And the foundation of React is JSX, which is crucial for proper developer experience, and requires a build step, so you can’t just slap a bunch of JSX files into a browser and call it a day. Nowadays when you say “I built this app with React” you don’t mean that you used it on one page or as a modern jquery alternative. You mean that you built everything around react, with its ecosystem, its best practices, etc. And with all those points in mind, I’d rather call react the framework, than a library

Viktor S. – Staff Engineer at Flatlogic.com

We also conducted the research among others software engineers and would like to share with you the most impressive arguments on this point. 

So, is React a Framework or a Library?

React is a Library

React is a JavaScript library for building user interfaces. It is maintained by Facebook and a community of individual developers and companies. React can be used as a base in the development of single-page or mobile applications.

Now Why Library, not a Framework?

different definitions for library and framework:

a framework is a software where you plug your code into
a library is a software that you plug into your code

In terms of this definition, React is a framework. But some people, especially in the frontend world, say a framework has to bring stuff like routers and/or widgets, etc. 

So Angular, and ExtJS are frameworks, but React isn’t, because it only gives you the means to build components and render them into the DOM.

Let’s make it simple, in React we have to include packages for everything it’s not necessary but yes we can add them, thus React is a Library but if we are not given an option to do so with our code then that’s a framework like Angular and Vue.

React is a library because it’s only supposed to deal with the view part of the eco-system, and you can integrate it easily in any project you’re working on currently, it’s something like jQuery, it only helps you with organizing your views into reusable components, of course, the performance is one of the best things about React, especially with the new Fiber algorithm, things will be faster seeing the scheduler mechanism, unlike Angular, it’s a framework that gives you everything you need, most of the things are already built-in, for React you need to create your own/or grab some modules from npm to add extra functionality as need per your project.

It depends on how you use it. If you’re writing a small program and you structure your program around working with React, you are probably thinking of React as a framework.

If you have a big program and you use React as a small part of it just for handling output, then you’re probably thinking of React as a library.

If your program is 90% user interface, and not only your program structure but your data structures are shaped to fit the React system, then you may even think of React as a language. Hey, if TypeScript can be a language, why not React?

React is a library, cause it has mostly evolved into a vast ecosystem that is barely distinguishable from a framework. A framework protects the edges, whereas a library provides a tool for doing certain tasks. React handles exactly one task: abstracted Web Components. It offers an internal state, lifecycles, and external properties, as well as a renderer for a browser or comparable environment through ReactDOM – and nothing more.

This has a few advantages: it is smaller than a full-featured framework, has fewer opinions on how to address problems, and so provides more options.

I’d say React is a library posing as a framework. It feels like working in a framework (esp. with JSX, though using that is optional), but under the hood, it is just a library. This definition is quite good:

a framework is software that you plug your code into (e.g. you work “inside” it).
a library is software that you plug into your code (e.g. you “hand-off” certain tasks to it, or build “on top” of it).

React feels like the first, but is the second. The attached video compares React and Angular and hints at the distinction. Since React treats your code as a black box, you can push the data-binding concerns out to the edges of your system, to be “handed off” to React (i.e. how you would use a library). Angular, on the other hand, forces you to work “inside” their “scopes” using their “directives” to handle data-binding. In Angular, you are passing your data through scopes that observe your data model. You are always at the mercy of whichever directives they are building into their framework scaffolding. You are also working “inside” HTML (JS-in-HTML), with all the constraints that impose (giving more of a framework feeling). But with React, you have less of that feeling, since you have freedom (full power of JS), and can build “on top” of React (HTML/JSX-in-JS). This is good since JS is inherently more powerful than HTML.

React is a Framework

React is a framework. Honestly caring about the difference between a library and a framework is a bit pedantic, so I’d say you can call it either. Having said that, my definitions of the two words are that a library is a collection of functions, and a framework is a way of doing things.

By this definition, React is a framework because it forces you to build UI in the React way instead of the Angular, etc. On the other hand, the dash is a perfect example of a library because it’s just a collection of functions, use them however you want.

JavaScript is known for its abundance of new plugins, frameworks, and other things created by its massive community of developers and designers.

You must be wondering what this fact has to do with the React JS framework and other frameworks. The truth is that many of the leading IT firms have already embraced JavaScript and leveraged its benefits.

That should answer the question and not cause any other debates, right? Well, not exactly; the debate over Is React a framework or library? is as strong as ever.

Over the years, developers, software engineers, and developer communities came up with pros and cons related to the status of React as a library or React as a framework. Let’s analyze them together.

React as a library

React can be easily swapped by some other javascript library offering similar functionalities.
React can be easily plugged into an existing technology stack – and that’s the definition of a library.

React as a framework

Related libraries must work in an opinionated way.
Because of its state and lifecycle on the components, you inverted the control to React.

Are you asking why React was designed as a library and not a framework [1] or why it is classified as a library and not a framework [2]?

[1] Why it was built that way. A library is something you can add to an existing project to enhance it. It does not impose any restrictions or conventions on your application design and you can supplement it with other libraries of your choice to flesh out your application. There is also a shorter learning curve (usually) on a library as you can add it incrementally to your project. A framework on the other hand implies structure and convention, you need to follow the conventions of the framework. In many cases a framework limits you to working within these conventions – you cannot (or it is difficult) to mix a framework with other code.

There are use cases for each.

[2] Why it is not classified as a framework. Based on the definition of a framework it does not fit the bill – it is a library that is added to your code – it does not impose structure – beyond the use of the library itself and it can be mixed in with other code.

React does not solve any structural or architectural problems on the app level. It provides us with a set of methods for better (in my opinion) handling of the front-end. I remember when jQuery did that back in the day, and how that started the revolution… React is now doing the same, just better.

Because React is a library eventually we got Flux and Redux. Both of them are handling real-world problems that come alongside Scaling. Mare library does not think about that.

React is a framework because Redux is referencing it as one (Source). Ah, as I started to hope that something in life is going to be easy. With React and Redux there is a clear layer of separation between the view and data. That is why React is not a complete framework to solve the entire problem.

Conclusion

Soft engineers spend a lot of time talking about what React is. The answer is important for any React soft engineer, no matter their skill level. That is because it indicates what they should know and how they should work when developing any React application. Depending on who you are, a beginner or an advanced React soft engineer, I hope this thoughtful research will improve your development process as you build your next React project.

The post Is React a Framework? Software Engineer Answering appeared first on Flatlogic Blog.Flatlogic Admin Templates banner