Forem: Temitope Omotunde

Environment Variables In Serverless Framework

Temitope Omotunde — Tue, 24 Jan 2023 00:55:49 +0000

*It is established standards not to put secrets in codebases because of security. Usually the secrets are introduced to
during deployment or code execution.

For Serverless Framework, it is no different. To introduce environment variable at deployment through the serverless.yml file,
use the environment key under provider key. *

...

provider:
  name: aws
  runtime: nodejs14.x
  environment:
    PERSON: tope
    STORE_KEY_ID: 34444

...

In code, you should be able to get the PERSON and STORE_KEY_ID environment variable as


const {PERSON, STORE_KEY_ID} = process.env

But there is still a security issue here, the serverless.yml is stll in your repository and anyone can have access to the value
just by checking the serverless.yml file.

I would like to look at 2 ways, this problem can be solved.

Introducing the environment variables into the environment where the deployment process for the serverless application happens and letting the serverless.yml reference those values.

...

provider:
  name: aws
  runtime: nodejs14.x
  environment:
    PERSON: ${env.PERSON}
    STORE_KEY_ID: ${env.STORE_KEY_ID}

...

The question of having the environment variables in the environment depends on the environment. Usually most CI platforms like Github Actions
have ways for you to sepcify the secrets you want interjected into your CI environment. For Github Actions, these are called Action Secrets and
you can find more in the video link https://www.youtube.com/watch?v=3bz0IR-GDIw .

What i want to focus on now is how to introduce these variables into the environment locally. It turns out Serverless framework can read
from a .env file without any 3rd party plugin. All you just need to do is

Add a .env to you folder, same level as your serverless.yml file with content

PERSON=tope
STORE_KEY_ID=1234

Add key useDotenv to the your serverless.yml file. This causes serverless to load environmental variables automatically from .env.

...

useDotenv: true

provider:
  name: aws
  runtime: nodejs14.x
  environment:
    PERSON: ${env.PERSON}
    STORE_KEY_ID: ${env.STORE_KEY_ID}

...

NOTE: this not make it automatically appear in your code, you still need to pass each of the environment to one in the environment key under provider.
Don't forget to add your .env to your .gitignore file to prevent the file from being pushed to your central repository.

By passing in variables as serverless parameters from the Serverless Dashboard. Serverless Dashboard helps you store secrets that can be used accross different team members. Generally use the .env file for local development and testing and use the secrets in Serverless dashbord for deployment in your CI.

This is not an arcticle on Serverless Dashboard but let me show you where it seats in the serverless deployment process.
The first time I used serverless framework , it was basically like this

[serverless framework on machine] ====== deploy ====>  [AWS]

All AWS secrets and other secrets are introduced during deployment from the machine. This machine genrally was your local device.

Now it is like this

[serverless framework on machine]  =====> [Serverless Cloud] ====== deploy ====>  [AWS]

All AWS secrets and other secrets are introduced during deployment from the Serverless Cloud. This adds security and removes the risk of
anyone jsut being able to deploy since there are security access check between any machine and the Serverless Cloud.

The Serverless Dashboard is the dashboard for the Serverless Cloud. One of the things is does is the ability to store secrets as parameters.
To access to parameters in your serverless.yml is shown below

...

provider:
  name: aws
  runtime: nodejs14.x
  environment:
    PERSON: ${param.PERSON}
    STORE_KEY_ID: ${param.STORE_KEY_ID}

...

So how do you write your serverless.yml so it can work with both .env locally and parameters when going through the Serverless Cloud?
Serverless framework gives us an easy way to do that

...

useDotenv: true

provider:
  name: aws
  runtime: nodejs14.x
  environment:
    PERSON: ${param.PERSON, env.PERSON}
    STORE_KEY_ID: ${param.STORE_KEY_ID, env.STORE_KEY_ID}

...

It checks for param.PERSON and falls back to env.PERSON. This helps make our serverless.yml very flexible.
For some properties, this can be extended

PERSON: ${param.ENV, env.ENV, 'dev'}

NOTE, do not use this for sensitive information, check only the param and the .env file.

Please reach out with any questions or clarifications you need.

Simple Web Crawler Service

Temitope Omotunde — Sat, 18 Sep 2021 18:39:33 +0000

This was built based on the Backend Project Idea 1 given in the article https://hackernoon.com/15-project-ideas-for-front-end-back-end-and-full-stack-web-developers-j06k35pi

Find project repository at https://github.com/topeomot2/simple-web-crawler-service

Requirements

Simple web crawler service that takes a page URL and returns the HTML markup of that page.
Only handles absolute urls.

GET /?url={page absolute url}
Host: localhost:3000

Response
status: 200 OK
content-type: json
body: {
    data: "html Content"
}


GET /?url={wrong string}
Host: localhost:3000

Response
status: 400
text: 'send absolute url with protocol included'

Installation

    npm install
    npm start

Libraries used

Express

Personally, my go to web framework for Node.js apis.

Express actually lives up to the definition on its site. It is Fast, unopinionated, minimalist Framework for Node.js. The unopinionated and minimalist can be a blessing or a curse, depending on what your preferences are.
It means you need to make decisions on what tools you want to use. Express makes no assumptions for you.

But no worries, with the express-generator, spinning up a basic api is simple.

The code below creates a project with express and some folder and setup opinions. The --no-view means we are not using any view template engines.

    npx express-generator
    express --no-view simple-web-crawler-service

Find out more at https://expressjs.com/en/starter/generator.html

Validator

A library of string validators and sanitizers. Chose this because of the simple isURL function it has which helps us check if the url query parameter is an absolute url with the protocol set.

Never use external inputs to your api without validation and sanitization

    if (!req.query || !req.query.url 
        || !validator.isURL(req.query.url, 
            { require_host: true, require_protocol: true })) {
        return res.status(400).send('send absolute url with protocol included')
    }

Axios

A very simple promise based HTTP Client. If you know how to use Promises, using Axios will be a breeze. This does all the work of retrieving the content of a page by making a GET request to the url.

   const axios = require('axios')

    async function getContent(url) { 
        try {
            let response  = await axios(url)
            return response.data
        } catch (error) {
            return null
        }


    }

Jest

Jest is a JavaScript Testing Framework. It works for any form of JavaScript code or anything that compiles to JavaScript i.e TypeScript. It is simple and I would recommend it anytime. It is the only testing framework I use in JavaScript.

install as a devDependency

    npm install jest --save-dev

add the following line in the scripts section of package.json.

    "test": "jest --coverage --watchAll"

--coverage : you want jest to create a coverage report
--watchAll means you want continuous checking of code change and rerunning tests. (This is good for TDD, but can be removed if not desired)

The test can be found in the tests/app.test.js file.

Supertest

The most important tests you can write for apis (and software in general) are integration tests. For apis, "route tests" are the integration tests. Supertest

Route tests are tests that actually call endpoints in the apis and tests for the happy path and sad paths. Supertest is the package for write route test. Supertest is built on superagent, which is an HTTP request library. So your Express app is actually called like if a user was making a request

Happy path is when you call the api correctly with all the expected parameters, you should the correct successful response. Below is a test that checks the response for the happy path.

The sad path is when you call the api incorrectly and you expect api to respond with the agreed response.

But something very important to note, calling apis this way means that all dependencies will be called. Dependencies include things like Databases, 3rd party apis etc. There are 2 ways practically to handle dependencies

Mocking: This is the process of substituting the response from 3rd dependencies so that they are not actually called during the test. This is the approach used here. Instead of using the crawler.js module to call the url, I used Jest to Mock the module and return a response. This makes the test faster and more predictable.
Containerization: this is good for database dependent apis, instead of mocking the database, you can just spin up a container for that database, seed it (fill it with test data) and then run your test against it. This can also be used for other infrastructural dependencies that the pai depends on.

Note: You can also use Mocking for the situation described in the Containerization section. I would advise that database are encapsulated in a service/model and then you can then mock the service/model

This is the first of many project ideas, I want to get done. Most of them will be picked from project ideas, I find online. Please reach out with any advice, improvements or corrections you feel that is needed.

Basic Concepts for Beginner Software Engineers - How the Internet Works

Temitope Omotunde — Mon, 17 May 2021 08:36:16 +0000

This is a series of basic concepts Software Developers should know. After many years of working as a Software Engineer, I have found out that knowing this concepts can clear up a lot of difficulty in understanding more advanced concepts in programming.

My approach is to explain each concept in basic terms and with easily understood examples. This is mainly for individuals who are new to software engineering, hence the oversimplification of more advanced concepts, or anyone who wants to understand more about certain concepts.

The Internet

Before we can understand what the internet is, let us look at this scenario.

Imagine yourself on a desktop computer, you would be able to use the software on your computer to do things like create word documents. Some years ago before the internet, if you were creating the documents for yourself, then you had no issues but if it was for other individuals to view on their own computers, you had the following options to get it to them.

Copy it on a storage device e.g Floppy Disk (just showing my age) or USB Flash Drive and give it to an individual to view on his/her computer. For multiple users, they would either have to take turns copying the document or they each get a storage device with the same document. This was true even if all the desktops were in the same room.
As time went along, computers in the same relative area could be connected together to form a network using cables or a wireless router. Instead of copying the document to a storage device, there could be a shared folder, where you could drop the document and other computers on the network could pick it up. Wow what a vast improvement. But it only worked for computers within the network. This network were limited by distance.
The epitome of all network is the Internet. The internet is a GLOBAL NETWORK that connects all other networks. It is made up of over a billion computers, cables, WiFi towers, satellite and other infrastructure. Everything works together to take simple idea of a network and make it global. On the global network, different software have been created that solves our document sharing problem for us. We can email the documents to users. We could use a file sharing service like We Transfer. These solutions remove the limitation of geography.

The concept of the internet brings up different questions.

How do all the machines on the internet work together?

All the infrastructure and computers that make the internet work are made by different manufacturers. Windows Desktops alone are made by HP, Dell then routers by another set of makers. These are just part of the billion devices that work together to make the internet function. How did all this manufacturers make all their devices work together?

This brings us to the concept of protocols.

Protocols are agreements made by a set of bodies (made up of Individuals and Companies) around certain aspect of communication on the internet.

These bodies include the Internet Engineering Task Force and the World Wide Consortium (W3C).

There are protocols controlling every aspect of the internet. They allow the seamless communication across different devices (computers, mobile phones, cars, ...) by different makers (HP, Apple, Tesla, ...).

When a Device Manufacturer wants to make a device to be used on the internet, the device must follow all the Protocols agreed upon. Usually the Device Manufacturers are part of the group that. come up with this agreements.

Popular example of Protocols are

Transmission Control Protocol (TCP)
File Transfer Protocol (FTP)
Internet Protocol (IP)
Simple Mail Transfer Protocol (SMTP)

Without Device Manufacturers sticking to the Protocols, there would be no internet today.

How do devices know how to find each other?

Devices on the internet are like post office mail boxes, each has an address. The protocol that controls the addresses of devices on the internet is the Internet Protocol (IP) and every device has an Internet Protocol (IP) addresses.

The most widely used version of the Internet Protocol is the version 4 (IPv4). Each device connected to the internet, gets a unique, numerical address like 154.120.70.149 .

Whenever you send from one device to another on the internet, the message is sent along until it gets to a device with the IP address. Everything on the internet is at a location usually a Server which has an IP address including websites we go to.

What are domain names?

Domain names were introduced as easier to remember and use addresses for devices on the internet. Instead of 154.120.70.149, you use https://example.com.

How does the internet know the IP address to go to when you type in your domain name?

This is where Domain Name Servers (DNS) come. They map domain names to IP address. A typical flow involves

enter https://example.com in the browser address bar
if your browser cache has no entry for the domain, it requests it from the Domain Name Server
An IP address is returned to the browser for caching and the browser request is made.

This basic simplified view of the internet will give you a simple picture of how things work and is something I wish I had when I started my software development journey.

The Prototype Inheritance in JavaScript is not an Accident

Temitope Omotunde — Thu, 06 May 2021 08:04:02 +0000

I wonder why i had this gut feeling when working with JavaScript that the Prototype Inheritance was an accident. After thinking about it, I realize, it was because of the following reasons

I had written other languages before coming to JavaScript and those languages were main Object Oriented Languages or Functional like PHP, C++, Java etc
Most of the materials I read to learn JavaScript never got to Prototypes until the end and after classes, which ensured that I had written a little JavaScript the way I wrote in other languages before finding out it had its own inheritance mechanism

In the ECMAScript specification which JavaScript is based off, after introducing the primitive types, you are introduced immediately to Prototypes in the next section which talks about Objects. It was critical for the developers that came up with the ECMAScript specification.

What is a Prototype

To understand what a prototype is, we must know some basic things about JavaScript

Apart from the primitive types, almost everything is an Object. A function is simply a callable object. Even the primitive types have Object versions. The Number Object is the object version of the number primitive type.

The second which is the more interesting one (in my opinion) is the use of constructors. (Please remove your OOP brains for now, this has nothing to do with class constructors). These constructors are functions which when called with the new keyword creates a new Object. The code inside the constructor is then executed to initialize some or all of the object properties by initializing them.

Below is an example of a constructor. In JavaScript, there are a lot of inbuilt constructors that we use, a major example is the Date function.

Every constructor has a property called a prototype. This prototype is an Object which means you can set properties on it.

Objects created from the same constructor also have a property called "prototype" which reference (simply point to) the prototype of the constructor. They all point to the same prototype meaning they all see and share the same constructor prototype. Continuing from our example above, it means they should all see the same value for height since height is on the constructor prototype.

As you can see from the result above, object1 and object2 have different names but they have the same height.
The question then becomes there is no height in the constructor but on its prototype, how did the JavaScript engine get the height correct. This brings us to Prototype-based Inheritance.

Prototype chain means when you call for a property in an Object, if the property is not in the Object itself, JavaScript will look at the prototype of the Object which in our example points to the constructor's prototype and since there is a property height, that is the value for height for the original Object.
Note that since the prototype of objects are Objects themself, there is nothing that stops you from pointing them to another object. Personally I believe in allowing the JavaScript engine manage the prototype referencing because I believe it was not meant to be used that way. Take for example the image below

Calling the prototype property on the object2 gives undefined not because it does not exist but you are not suppose to access it directly (my opinion). But note that calling prototype on the constructor gives the prototype Object. This is deliberate and not an accident.

Constructors are like the base for other Objects. Shared properties between Objects should be on the constructor prototype. The prototype of objects are internal mechanisms for inheritance in JavaScript and should avoid setting it directly.

For Object prototype, a special accessor property called proto was introduced by browsers but is not included in the ECMAScript language spec. So please avoid using it in your code.

Finally if you follow the prototype chain down until you get to the constructor prototype, this usually ends in the built-in type Object. This is where all the Object functions we use are like hasOwnProperty, toString, valueOf.

As much as it seems odd, the prototype inheritance in JavaScript is not an accident. It is how it is built and understanding it will help you write better JavaScript code.

Flutter: Everything is a Widget Series -- Part 4: MaterialApp

Temitope Omotunde — Mon, 23 Sep 2019 09:06:58 +0000

One of the main themes that quickly jump at you while using Flutter is that everything is a widget. This series aims to help beginners understand this simple yet powerful concept and introduce them to basic widgets in Flutter.

To help us in this journey, I built a Twitter Mobile Clone App using only the inbuilt widgets that come with Flutter. You can find the code at https://github.com/topeomot2/twitter-ui-app

Every Flutter app starts from a call to main(), which calls the runApp command. The runApp commands simply set up the root widget of the Application. We simply feed the command with the root widget and we start building our widget tree from there.

void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Twitter UI',
      theme: new ThemeData(
          primaryColor: DarkModeBg,
      ),
      home: TwitterHomePage(),
    );
  }
}

MaterialApp

According to the Flutter SDK comments

A MaterialApp is an application that uses material design.

Material Design is a design language that was introduced by Google in 2014. By design language, we mean guidelines that help to give a unique but consistent look and feel. So Material Design is one such design language that has become popular from Applications on Mobile and Web.

Every major framework has a port of Material Design elements that are available for use.

Material-UI: A popular React UI framework

Vue Material Design Component Framework - Vuetify.js

For Android Applications, Material Design has become the defacto standard and is encouraged by Google. There are sets of components (designed with the material design guidelines)that are expected in a material design application.

Material Design for Android | Android Developers

Flutter and Material Design

The Flutter team also wants these components available to developers.

They came up with a convenience widget that wraps several widgets that are commonly required for material design applications.

This convenience widget is called MaterialApp. So if you want to build an application that uses the material design guidelines out of the box, you simply wrap your screens in a MateriaApp widget and you get some awesome prebuilt widget.

Flutter Material Components widgets

CupertinoApp

Material Design Language is not the only one supported in Flutter. Material Design Language is used a lot in Android Applications, for IOS applications, we have the Cupertino Design Language.

And the convenience widget that makes this available in flutter is the CupertinoApp.

Flutter Cupertino (iOS-style) widgets

I use one of these design languages to give my app a consistent look and feel so that they look like applications that were built with the native SDKs either in Android and IOS. They save a lot of time.

Merge-Descriptors Library | JavaScript Library Code Breakdown

Temitope Omotunde — Mon, 02 Sep 2019 05:13:02 +0000

The Merge-Descriptors library is a NodeJs package with more than 8.5million download/week and used by Express.

In this video, you will learn

What merge-descriptors are
Merging JavaScript Objects
How merge-descriptors package works

ReadCode TV is a youtube channel where I go through the codes of libraries to see how they work and learn about different programming concepts and techniques and how they have been applied. The aim is to help us become better programmers. The libraries will come from different languages including JavaScript, Java, Kotlin, PHP, Dart and other languages that I work with.

Click here to subscribe.
Follow ReadCode TV on twitter

Flutter: Everything is a Widget Series -- Part 3: State in Widgets.

Temitope Omotunde — Wed, 21 Aug 2019 21:37:06 +0000

To help us in this journey, I built a Twitter Mobile Clone App using only the inbuilt widgets that come with Flutter. You can find the code at https://github.com/topeomot2/twitter-ui-app

Before going on to the different widgets we need to look at the concept of "State". This is not a term unique to Flutter but can also be found in other languages, the most well-known being React.

State generally means a set of properties that determine what "situation/condition" the application is in. One of the best analogy I have seen is the comparison of temperature as a State property that determines the "condition" of water. Increase the temperature to 100⁰C and above, water becomes steam (gaseous state), below 0 ⁰C, water becomes ice (solid state).

Generally, State exists at different levels of the application. State Management is a major topic and articles can be found online. This link includes a more technical look into state.

For State at the widget level, Flutter gives us a State Class. Below is from the comments in the Flutter source code for the class.

"State is information that (1) can be read synchronously when the widget is built and (2) might change during the lifetime of the widget."

Based on whether a widget has a State Class attached to it or not, there are 2 basic widget types in Flutter, the Stateless Widget and the Stateful Widget.

Stateless Widget

From the Flutter source code

StatelessWidgets class are for widgets that always build the same way given a particular configuration and ambient state.

Stateless Widgets do not have a State class attached to them. Whatever configuration was passed during the widget creation cannot be changed internally by the widget itself. Below is an example of a Stateless Widget.

class StatelessSample extends StatelessWidget {

  final int count;

  const StatelessSample({Key key, this.count}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Container(
      child: Text(count.toString(),
        style: TextStyle(
          color: Colors.white
        ),
      ),
    );
  }
}

Note, anything you want to come into the widget during creation must come in through the constructor and they must be declared final. Meaning if you pass in the same configuration, you will always get the same state in your widget.
The widget creates its own UI by returning a widget in its own build method.
Nothing in the widget can change the UIof the widget directly after it has been created. Only a total recreation by passing in another “count” externally can change the value of count being displayed.

For the reason above, Stateless Widget are ideal for sections of the User Interface used mainly for displaying information and obviously the information must be passed into the constructor.

Stateful Widget

From the Flutter source code

A StatefulWidget is a widget that has mutable state.

Let us look at a simple example.

class StatefulSample extends StatefulWidget {

  final int count;

  const StatefulSample({Key key, this.count}) : super(key: key);

  @override
  _StatefulSampleState createState() => _StatefulSampleState();
}

class _StatefulSampleState extends State<StatefulSample> {

  int count;

  @override
  void initState() {
    super.initState();
    count = widget.count;
  }
  @override
  Widget build(BuildContext context) {
    return Center(
      child: Column(
        children: <Widget>[
          Container(
            child: Text(count.toString(),
              style: TextStyle(
                  color: Colors.white
              ),
            ),
          ),
          RaisedButton(
            child: Text('Increase Count'),
            onPressed: (){
              setState(() {
                count += 1;
              });
            }
          )
        ],
      ),
    );
  }
}

Please note the following

There are 2 classes when it comes to Stateful Widget, a class that extends the inbuilt Flutter StatefulWidget itself and another class that extends the inbuilt State class. Every StatefulWidget must have a State class attached to it through the createState method.
The actual UI of the Stateful widget comes from the State object that is attached to it. You indicate the UI by returning a widget in the build function of the state.
The State class has a setState method, which the Flutter source code says “Notify the framework that the internal state of this object has changed”. This function notifies the framework which reruns the build function again with the updated properties of the state.
So even though the external “count” cannot be changed since it is final, we can update the UI because we are using an internal count variable of the State object and we are rebuilding the UI by calling setState();
iniState is a method that is called once during the initialisation of any State object. We set the initial value of our internal count variable from here.

The properties above make Stateful Widgets ideal for container widgets which control the display of other widgets.

No matter which you use, the build method in a Stateless or Stateful Widget is where you will return what you want displayed. As we learnt in the last lesson this can be simple inbuilt widgets or complex compositions.

Flutter: Everything is a Widget Series -- Part 2: Composition is Key.

Temitope Omotunde — Sun, 11 Aug 2019 22:18:33 +0000

To help us in this journey, I built a Twitter Mobile Clone App using only the inbuilt widgets that come with Flutter. You can find the code at https://github.com/topeomot2/twitter-ui-app

Every Flutter app starts from a call to main(), which calls the runApp command. The runApp commands simply set up the root widget of the Application. From here onwards we are building a tree of widgets with the root widget as the origin.

In Flutter, Widgets are the building blocks for other Widgets and the UI.

The technique used for this is Composition. You use widgets to compose other widgets and your UI (which can be seen as one giant widget) is composed of widgets too. We will use 2 examples to illustrate this.

Twitter Mobile Clone App Widget Tree

To illustrate this, below is a section of the widget tree for the Twitter Mobile Clone App.

Note the following

MyApp Widget is the root widget. This will be loaded by a call to the runApp() in the main function.

void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Twitter UI',
      theme: new ThemeData(
          primaryColor: DarkModeBg,
      ),
      home: TwitterHomePage(),
    );
  }
}

Widgets are not only for content but they are also for structure. Examples of such widgets are Column, Row, Padding, SizedBox, etc. Everything in Flutter development is a widget, even if they do not contain any content like text, images, etc. Everything extends to things like color, alignment, etc
Widgets of a particular type can be reused as many times as is required.

As I said, we will be going through all these widgets in this series.

RaisedButton Widget

The RaisedButton is one of the Button widgets inbuilt that comes with Flutter in the MaterialApp library. Below is the constructor code for a RaisedButton.

const RaisedButton({
  Key key,
  @required VoidCallback onPressed,
  ValueChanged<bool> onHighlightChanged,
  ButtonTextTheme textTheme,
  Color textColor,
  Color disabledTextColor,
  Color color,
  Color disabledColor,
  Color highlightColor,
  Color splashColor,
  Brightness colorBrightness,
  double elevation,
  double highlightElevation,
  double disabledElevation,
  EdgeInsetsGeometry padding,
  ShapeBorder shape,
  Clip clipBehavior = Clip.none,
  MaterialTapTargetSize materialTapTargetSize,
  Duration animationDuration,
  Widget child,
}) : assert(elevation == null || elevation >= 0.0),
     assert(highlightElevation == null || highlightElevation >= 0.0),
     assert(disabledElevation == null || disabledElevation >= 0.0),
     super(
       key: key,
       onPressed: onPressed,
       onHighlightChanged: onHighlightChanged,
       textTheme: textTheme,
       textColor: textColor,
       disabledTextColor: disabledTextColor,
       color: color,
       disabledColor: disabledColor,
       highlightColor: highlightColor,
       splashColor: splashColor,
       colorBrightness: colorBrightness,
       elevation: elevation,
       highlightElevation: highlightElevation,
       disabledElevation: disabledElevation,
       padding: padding,
       shape: shape,
       clipBehavior: clipBehavior,
       materialTapTargetSize: materialTapTargetSize,
       animationDuration: animationDuration,
       child: child,
     );

Note the method parameter, ButtonTextTheme. This expects a Widget which expects a ButtonTheme Widget which itself extends an inheritedWidget.
The child parameter is of type Widget. It means we can pass a widget to this widget. Usually, a widget has either a parameter called either "child" or "children" depending on the widget itself. Column and Row widgets have a "children" parameter while a container has a "child" widget.
This principle of properties of Widgets containing other Widget is used throughout Flutter.

For Android Developers

As an Android Developers who use Java or Kotlin, this composition method in Flutter which leads to a lot of layers in your UI hierarchy which is something that is frowned upon when developing in those languages. In developing with Java and Kotlin with the Android ADK we aim for shallow hierarchy because the greater the number of layers in your UI hierarchy the slower thee app becomes.
Flutter does not suffer from this type of limitation. How does Flutter manage this?

Flutter has a layout algorithm that builds the UI from the Widget Tree at sublinear performance. The worst-case scenario will be Linear O(N) during the initial layout and sublinear (< O(N)) for subsequent UI update where N is the number of widgets.

The combination of the sublinear layout algorithm other factors means you should not be scared of composing widgets.

Composition is Key

As you aim to become a better Flutter developer, keep in mind, widgets are the building block, composition is the technique for creating a building from the blocks.

Flutter: Everything is a Widget Series -- Part 1: Where Flutter fits in.

Temitope Omotunde — Wed, 07 Aug 2019 22:41:12 +0000

One of the main themes that quickly jump at you while using Flutter is that everything is a widget. The aim of this series is to help beginners understand this simple yet powerful concept and introduce them to basic widgets in Flutter.

To help us get more insight into Flutter, I decided to build a Twitter Mobile App UI but with the following constraint.

Use only widgets that come out of the box in Flutter.
Do not use external libraries.

For any point at which I deviate, you will be notified and given a reason. Below is the result and you can find the project at https://github.com/topeomot2/twitter-ui-app

Below is a compiled list of the widgets used. We shall look at some basic concepts and look at each of the widgets used in this series.

Container
Column
Row
Text
SizedBox
Expanded
Icon
Divider
Padding
TextStyle
Card
Scaffold
AppBar
ListView
ListTile
CircleAvatar
Drawer
MaterialApp

An important feature of Flutter is its simplicity. Flutter is very simple, but also very powerful. And my aim in this series is to follow that same pattern and show its variety of use cases.

Where do Widgets come in?

To understand where widgets come in, we need to understand how development in Flutter works. To help, we’re going to look at the 2 major ways that applications have been developed for mobile platforms.

Native Development

In Native development, you write code which automatically makes use of the device OEM widgets for display and talks directly to the device services for capabilities like Bluetooth, camera, etc.
Did you notice? I said OEM widgets. Meaning you will have to develop for each platform separately. They are done in languages that are chosen by the OEMs. For Android, that is primarily Java and Kotlin, Objective C and Swift for IOS.

Pros: There is more access to device capabilities.
Cons: You have to develop separately for different platforms.

Cross Platform Development

For Cross Platform development, these are majorly HTML, JavaScript, and CSS in WebView. These WebViews cannot talk to the OEM widgets for UI and definitely not the device services.
The above translates to the use of a JavaScript Bridge, which acts as a layer between user code and the device capabilities. Because they talk through a bridge, you can write once and let the JavaScript Bridge do the work of talking to the native layer of whatever platform is there.

Pros: You get faster development since you only need to build once and it works on both Android and IOS.
Cons: This cannot utilize native device capabilities.

But what does Flutter do?

It introduces another paradigm by taking the best of both worlds.

Flutter uses the Dart programming language which is then compiled into native ARM Code, which means your apps built with Flutter have full access to device services and capabilities.
To deal with the different OEM widgets, Flutter totally avoids OEM widgets and builds its own widgets using its own renderer. This means widgets that look and feel like the native OEM widgets and adapts to their respective platform.
But these widgets are so customizable that you can build a totally different experience from what the OEM normal look and feel like. It is all up to you.

So Flutter gives you Native Capabilities while doing Cross Platform Development. The main backbone of building Flutter apps is the Widget and we shall be looking at them in greater detail in the coming articles in this series.