UPPFIRSTis in the E-Commerce Enablers Industry

UPPFIRST

uppfirst

Laravel's Strategy Pattern: The Manager Under the Hood

GraphQL is an API query language that allows clients to get the data they need more efficiently and flexibly than traditional REST APIs. In recent years, GraphQL has gained a lot of popularity and has become one of the most popular technologies for API creation. At the same time, Next.js is a highly efficient and scalable web application development framework that has become very popular with web developers. This tutorial will explore how to create a GraphQL server and client with Next.js to provide a more efficient and flexible development experience for our users. this tutorial assumes you have basic knowledge of GraphQL and Nextjs (pages directory). Before starting: We will use to make requests and retrieve fake JSON data, in particular, we will use dummyJSON https://dummyjson.com/docs/users Setting Up We create a new Next.js project with the following command and follow the steps indicated. This time we will use , you can use the package manager of your choice. pnpm pnpm create-next-app We install the dependencies that we will need in the project: pnpm install @apollo/server graphql @as-integrations/next apollo-server-core @apollo/client graphql-tag @nextui-org/react is the main library for Apollo Server itself. @apollo/server: An Apollo Server integration for use with Next.js. @as-integrations/next: to create and consume API’s in Graphql language. graphql: to create and manage GraphQL servers simply and flexibly. apollo-server-core: to handle GraphQL requests and statuses on clients. @apollo/client: to build and manipulate GraphQL queries in JavaScript. graphql-tag: library of user interface components. I will use this library only to quickly style the application, feel free to use the one you want. @nextui-org/react After that, we will create the following structure for the project: ...
├── src/
│   ├── graphql/
│   │   ├── queries/
│   │   │   ├── getUseres.gql
│   │   │   └── searchUser.gql
│   │   ├── apollo-client.js
│   │   ├── resolvers.js
│   │   └── schemas.js
│   ├── pages/
│   │   ├── api/
│   │   │   └── graphql.js
│   │   ├── _app.js
│   │   ├── _document.js
│   │   └── index.js
│   │   ...
│   ├── utils/
│   │   └── cors.js
├── .env.local
... Now we will create the file and create the environment variables that we are going to use: .env.local /* we add the prefix NEXT_PUBLIC_ to the variable that will havethe graphql server url defined, this way we will be able toaccess to it client side */

NEXT_PUBLIC_URL_SERVER_GRAPHQL=http://localhost:3000/api/graphqlURL_API=https://dummyjson.com/users Graphql server We will create the GraphQL server inside the directory since it’s where the server created by Nextjs lives. 1— /api : graphql.js import { ApolloServer } from "@apollo/server"
import { startServerAndCreateNextHandler } from '@as-integrations/next'
import { ApolloServerPluginLandingPageGraphQLPlayground } from "apollo-server-core"

import typeDefs from "@/graphql/schemas"
import resolvers from "@/graphql/resolvers"
import allowCors from "@/utils/cors"

const apolloServer = new ApolloServer({
  typeDefs,
  resolvers,
  plugins: [ApolloServerPluginLandingPageGraphQLPlayground()]
})

const handler = startServerAndCreateNextHandler(apolloServer, {
  context: async (req, res) => ({ req, res }),
})

export default allowCors(handler) The GraphQL server has two main parts: schemas (typeDefs) and resolvers. The schemas define the structure of the data and the queries that can be made to the server, while the resolvers define how the data is obtained and processed. We also add to the initial configuration of the server the definition of . This plugin provides a GraphQL playground page that allows us to test queries in a more user-friendly way. ApolloServerPluginLandingPageGraphQLPlayground Finally, is used to enable Cross-Origin Resource Sharing (CORS) support on the server. This function adds the necessary CORS headers to the response. allowCors : utils/cors.js const allowCors = (fn) => async (req, res) => {
  res.setHeader('Access-Control-Allow-Credentials', true)
  res.setHeader('origin', 'https://nextjs-graphql-server-client.vercel.app')
  res.setHeader('Access-Control-Allow-Origin', req.headers.origin || '*')
  // another common pattern
  res.setHeader('Access-Control-Allow-Methods', 'GET,OPTIONS,PATCH,DELETE,POST,PUT')
  res.setHeader(
    'Access-Control-Allow-Headers',
    'X-CSRF-Token, X-Requested-With, Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version',
  )
  if (req.method === 'OPTIONS') {
    res.status(200).end()
    return
  }
  await fn(req, res)
}

export default allowCors In this file, we have defined the basic headers that the app needs to be able to make requests to the Graphql server. This middleware is fully customizable to the requirements of your application, you can remove or add more headers, either known headers or custom headers that only your app uses. You need to add the necessary headers so you can make requests to the server either using this middleware or directly in your requests. Schema creation 2— : schemas.js import { gql } from 'graphql-tag'

const typeDefs = gql`
  type Query {
    users: [User]
    searchUser(value:String):[User]
  }

  type User {
    id: ID
    firstName: String
    lastName: String
    email: String
    username: String
    image: String
  }
`
export default typeDefs We define a GraphQL schema using . The function is used to convert a string into a valid GraphQL schema document. gql gql In the Schema, we define a query type called , which has a property called , which is a list of objects of type . Query users User We also have the query called which receives a string value with which we will filter the users that match the value. For this tutorial, we will create the type with only some of the API returned properties. searchUser User Resolvers creation 3— : resolvers.js const resolvers = {
  Query: {
    users: async () => {
      try {
        const response = await fetch(process.env.URL_API)
        const data = await response.json()

        return data.users.map(u => {
          return {
            id: u.id,
            firstName: u.firstName,
            lastName: u.lastName,
            email: u.email,
            username: u.username,
            image: u.image
          }
        })
      } catch (error) {
        throw new Error("Something went wrong")
      }
    },
    searchUser: async (_, { value }) => {
      try {
        const response = await fetch(`${process.env.URL_API}/search?q=${value}`)
        const data = await response.json()

        return data.users.map(u => {
          return {
            id: u.id,
            firstName: u.firstName,
            lastName: u.lastName,
            email: u.email,
            username: u.username,
            image: u.image
          }
        })
      } catch (error) {
        throw new Error("Something went wrong")
      }
    }
  }
}

export default resolvers We define the resolvers that correspond to each query. The resolvers request the external API, which returns a JSON with a list of users. We do a mapping of the data received from the API to return only the data that we will use in the application. In case something goes wrong during the request or the data processing, an exception is thrown with the message “Something went wrong”. Now let’s run the application, go to the path and execute the queries created: /api/graphql GraphQL client Creation of an instance of an Apollo client. 1— import { ApolloClient, InMemoryCache } from "@apollo/client" import { ApolloClient, InMemoryCache } from "@apollo/client"

const client = new ApolloClient({
  uri: process.env.NEXT_PUBLIC_URL_SERVER_GRAPHQL,
  cache: new InMemoryCache(),
})

export default client The client is created with two main properties: and . The uri property is the GraphQL API address to which the client will connect. In this case, we will use the environment variable created earlier that stores the API address. uri cache NETX_PUBLIC_URI_SERVER_GRAPHQL The property is used to store the data that is downloaded from the API in cache. This way, the client can access the data without making a new API query. cache This component provides functionality, which allows an instance of an Apollo client to access all components rendered within it. 2— ApolloPrivider import { ApolloProvider } from '@apollo/client'

import client from "@/graphql/apollo-client"

export default function App({ Component, pageProps }) {
  return (
    <ApolloProvider client={client}>
        <Component {...pageProps} />
    </ApolloProvider>
  )
} Creation of queries in files. 3— .gql : getUser.gql query getUsers {
 users {
  id
  firstName
  lastName
  email
  username
  image
 }
} : searchUser.gql query getSearchUsers($value: String) {
 searchUser(value: $value) {
  id
  firstName
  lastName
  email
  username
  image
 }
} : next.config.js const nextConfig = {
 ...
  webpack: (config, options) => {
    config.module.rules.push({
      test: /\.(graphql|gql)/,
      exclude: /node_modules/,
      loader: "graphql-tag/loader"
    })

    return config
  }
  ...
} In order to use or files in Next.js, it’s necessary to add a webpack configuration in the Nextjs configuration. .graphql .gql Here you can read more about it. Making server-side and client-side requests. 4— : index.js import { useEffect, useRef, useState } from 'react'
import { useLazyQuery, useQuery } from '@apollo/client'

import Head from 'next/head'
import { Button, Container, Grid, Input, Spacer, User, Row, Loading } from "@nextui-org/react"

import GET_USERS from '@/graphql/queries/getUsers.gql'
import SEARCH_USERS from '@/graphql/queries/searchUsers.gql'

export default function Home() {
  const [users, setUsers] = useState([])
  const [searchValue, setSearchValue] = useState('')

  const usersRef = useRef(null)

  const { data, loading, error } = useQuery(GET_USERS)

  const [getSearchedUsers] = useLazyQuery(SEARCH_USERS, {
    fetchPolicy: 'network-only',
    onCompleted(data) {
      setUsers(data.searchUser)
    }
  })

  useEffect(() => {
    if (data) {
      setUsers(data.users)
      usersRef.current = data.users
    }
  }, [data])


  const searchUser = () => {
    getSearchedUsers({
      variables: {
        value: searchValue
      }
    })
  }

  if (error) {
    console.error(error)
    return null
  }

  return (
    <>
      <Head>
        <title>Nextjs and Graphql Setup</title>
        <meta name="description" content="Generated by create next app" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main >

        <Container css={{ display: 'flex', justifyContent: 'center' }}>
          <Spacer y={2.5} />
          <Row justify="center" align="center">

            <Input
              clearable
              labelPlaceholder="User"
              onClearClick={() => setUsers(usersRef.current)}
              initialValue={searchValue}
              onChange={(e) => setSearchValue(e.target.value)}
            />
            <Button color="gradient" auto onClick={() => searchUser()}>
              Search user
            </Button>
          </Row>

          <Spacer y={2.5} />
          <Row justify="center" align="center">

            {loading
              ?
              <Loading />
              :
              <Grid.Container gap={2} justify="center">
                {users.map(u => (
                  <Grid xs={3}
                    key={u.id}
                  >
                    <User
                      src={u.image}
                      name={`${u.firstName}${u.lastName}`}
                      description={u.email}
                      size="lg"
                      bordered
                      color="gradient"
                    />
                  </Grid>

                ))
                }
              </Grid.Container>
            }

          </Row>
        </Container>
      </main>
    </>
  )
} In the above code, we will use the hook to get the users with the query and then save it in the state. useQuery GET_USERS We also use Apollo’s hook to perform a search on the users when the user clicks on the “Search user” button. When the query is finished we save the results in the state. useLazyQuery That’s it! now we can use graphql server-side and client-side. You can add as many queries and resolvers as you need. The app looks as follows: See the demo here Repo here Conclusion In summary, using GraphQL in a Next.js project can significantly improve the application’s efficiency, flexibility, documentation, security, and scalability. Hopefully, this will serve as a guideline for your future projects. Want to connect with the author? Love connecting with friends all around the world on . Twitter Read more: How to Create a Modern Skeleton Loader in React to Improve User Experience How to Simulate a Backend REST API with json-server for CRUD Development in React Also published . here

Setting up a GraphQL Server and Client in Next.js

If you know about the breadth-first search algorithm, and even if you don't, you will be able to easily understand Dijkstra's algorithm as we address it in this article. The Breadth-first Search of a Graph The first algorithm that I would like to describe is the search of a graph. breadth-first What is it? Let's step back from the formal description of graphs and imagine a picture. We lay out ropes on the ground, soaked in something flammable, of the same length so that none of them intersect, but some of them touch each other at the ends. And now we light one end. How will the fire behave? It will spread evenly over the ropes to neighboring intersections until everything ignites. It is easy to generalize this picture to three-dimensional space. This is what the breadth-first search of a graph will look like in real life. Now let's describe it more formally. Let us start the breadth-first search from some vertex V. In the next moment of time, we will examine the neighbors of vertex V (a neighbor of vertex V is a vertex that shares an edge with V). And so on until all the vertices in the graph have been examined. Implementation of breadth-first search Suppose we are in some vertex during the breadth-first search process. Then we will use a queue into which we will add all the neighbors of the vertex except those that we have already visited. void bfs(int u) {
  used[u] = true;
  queue<int> q;
  q.push(u);
  while (!q.empty()) {
    int u = q.front();
    q.pop();
    for (int i = 0; i < (int) g[u].size(); i++) {
      int v = g[u][i];
      if (!used[v]) {
        used[v] = true;
        q.push(v);
      }
    }
  }
} In this implementation, g is the adjacency list, i.e. g[u] contains a list of adjacent vertices to u (std::vector is used as a list), and used is an array that allows us to understand which vertices we have already visited. Here, breadth-first search does nothing except for the search itself. It may seem unnecessary, but it can be easily modified to find what we need, such as the distance and path from any vertex to all others. It should be noted that the edges do not have weights, i.e. the graph is unweighted. Here is an implementation of the search for distances and paths. void bfs(int u) {
  used[u] = true;
  p[u] = u;
  dist[u] = 0;
  queue<int> q;
  q.push(u);
  while (!q.empty()) {
    int u = q.front();
    q.pop();
    for (int i = 0; i < (int) g[u].size(); i++) {
      int v = g[u][i];
      if (!used[v]) {
        used[v] = true;
        p[v] = u;
        dist[v] = dist[u] + 1;
        q.push(v);
      }
    }
  }
} Here, p is an array of ancestors, i.e. p[v] is the ancestor of vertex v, and dist[v] is the distance from the starting vertex of the traversal to vertex v. How to restore the path? It's quite easy to do, just by traversing through the array of ancestors of the required vertex. For example, recursively: void print_way(int u) {
  if (p[u] != u) {
    print_way(p[u]);
  }
  cout << u << ' ';
} Shortest paths All further reasoning will be valid only if the edge weights are non-negative. Now let's move on to weighted graphs, where the edges of the graph have a weight, such as the length of the edge, the fee for passing through it, or the time it takes to pass through it. The task is to find the shortest path from one vertex to another. In this article, I will start with the breadth-first search and I don't recall seeing such an approach anywhere else. Maybe I missed it. So let's take a look at the breadth-first search implementation again, specifically at the condition for adding to the queue. In the breadth-first search, we only add to the queue those vertices that we haven’t been to yet. Now, we will change this condition and add those vertices whose distance can be reduced. Obviously, the queue will be empty only when there are no vertices left whose distance can be reduced. The process of reducing the path from vertex V is called vertex V relaxation. It should be noted that initially, the path to all vertices is infinity (take some sufficiently large value as infinity, namely, such that no path will have a length greater than the value of infinity). This algorithm directly follows from breadth-first search, and it was the first algorithm I came up with when solving my first problem of finding the shortest paths in a graph. It is worth mentioning that this method finds the shortest paths from the vertex from which we started the algorithm to all others. Here is the implementation: const int INF = 1e+9;

vector< pair<int, int> > g[LIM]; // In g[u] there is a list of pairs: (the length of the path between vertex u and v, vertex v).

void shortcut(int u) {
  fill(dist, dist + n, INF);
  dist[u] = 0;
  p[u] = u;
  queue<int> q;
  q.push(u);
  while (!q.empty()) {
    int u = q.front();
    q.pop();
    for (int i = 0; i < (int) g[u].size(); i++) {
      int v = g[u][i].second, len = g[u][i].first;
      if (dist[v] > dist[u] + len) {
        p[v] = u;
        dist[v] = dist[u] + len;
        q.push(v);
      }
    }
  }
} Why do we store such pairs in the adjacency list? It will become clear a little later when we improve this algorithm, but to be honest, for this implementation, the pairs can be stored the other way around. We can slightly improve the queue insertion process by introducing a bool array to mark whether the vertex that needs to be relaxed is currently in the queue. const int INF = 1e+9;

vector< pair<int, int> > g[LIM];
bool inque[LIM];

void shortcut(int u) {
  fill(dist, dist + n, INF);
  dist[u] = 0;
  p[u] = u;
  queue<int> q;
  q.push(u);
  inque[u] = true;
  while (!q.empty()) {
    int u = q.front();
    q.pop();
    inque[u] = false;
    for (int i = 0; i < (int) g[u].size(); i++) {
      int v = g[u][i].second, len = g[u][i].first;
      if (dist[v] > dist[u] + len) {
        p[v] = u;
        dist[v] = dist[u] + len;
        if (!inque[v]) {
          q.push(v);
          inque[v] = true;
        }
      }
    }
  }
} If you take a closer look, this algorithm is very similar to the Levit algorithm, but it's not the same, even though in the worst-case scenario it has the same asymptotic complexity. Let's make a rough estimate of this. In the worst-case scenario, we will have to perform relaxation each time we pass through any edge. The total is O(n * m). The estimate is quite rough, but it's enough for the initial stage. It's also worth noting that this is the worst-case scenario, and in practice, even such an implementation works quite quickly. And now, the most interesting part!... drum roll... Let's improve our algorithm to Dijkstra's algorithm! Dijkstra's Algorithm The first optimization that comes to mind is to relax only those vertices whose current path is minimal. This idea came to me one fine day, but as it turns out, I was far from the first. The wonderful scientist Edsger Dijkstra was the first to come up with this idea. Moreover, he proved that by choosing vertices for relaxation in this way, we will perform relaxation no more than n times! Intuitively, it is clear that if the path to a certain vertex is currently minimal, we cannot make it any smaller. You can read about it on . Wikipedia Now the only thing left to do is to understand how to efficiently find the vertex with the minimum distance to it. To do this, we will use a priority queue (heap). The STL has a class that implements it and is called . I will provide an implementation that, again, directly follows from the previous (described in this article) algorithm. priority_queue void dijkstra(int u) {
  fill(dist, dist + n, INF);
  dist[u] = 0;
  p[u] = u;
  priority_queue< pair<int, int>, vector< pair<int, int> >, greater< pair<int, int> > > q;
  q.push(make_pair(0, u));
  while (!q.empty()) {
    pair<int, int> u = q.top();
    q.pop();
    if (u.first > dist[u.second]) continue;
    for (int i = 0; i < (int) g[u.second].size(); i++) {
      int v = g[u.second][i].second, len = g[u.second][i].first;
      if (dist[v] > dist[u.second] + len) {
        p[v] = u.second;
        dist[v] = dist[u.second] + len;
        q.push(make_pair(dist[v], v));
      }
    }
  }
} Most likely it's not entirely clear what's going on here. So, let's start with declaring a priority queue. Here, the first template argument is the data stored in the queue, specifically pairs of the form (distance to the vertex, vertex number). The second template argument is the container in which the data will be stored, and the third argument is the comparator (which, by the way, is found in the functional header file). Why do we need a different comparator? Because with the standard declaration of , we'll only be able to extract the vertices with the maximum distance, whereas we actually need the opposite. The asymptotic complexity of this solution to the problem is O(n * log(n) + m * log(n)). priority_queue< pair<int, int> > Indeed, we only have n relaxations, and we can find the vertex with the minimum path length to it in log(n) time (which is the asymptotic complexity of the standard priority queue implementation in the STL). It should also be noted that we may end up adding the same vertex to the queue with different paths to it. For example, we may have relaxed from vertex A, whose neighbor is vertex C, and then relaxed from vertex B, whose neighbor is also vertex C. To avoid problems related to this, we simply skip the vertices that we extracted from the queue, but whose distance from the queue is no longer relevant, i.e. greater than the current shortest path. This is why the implementation includes the line "if (u.first > dist[u.second]) continue;". Conclusion It turns out that it is actually very easy to implement Dijkstra's algorithm with a time complexity of O(n * log(n) + m * log(n)).

Exploring Graph Traversal: From Breadth-First Search to Dijkstra's Algorithm

Imagine writing increasingly complex requirements. More than just the retrieval of one entity by primary key, especially if you run it in a loop or in an environment that is extremely intolerant of long-duration queries. In more complex cases, you also don’t have access to the production database and execute a real query on live data and production hardware. How do you process rough estimates of SQL query execution? Stages of implementation Each database runs a query through the standard process (with some deviations depending on dB implementation): Syntax parsing Semantic parsing Planning Executing The most time-consuming part is usually executed only because the database must go to disk, get some data and send it to the client. Other parts of the process go mostly to the CPU and use some cached metadata. The planning creates schemes, compares them, selects the best one, and sends it to the executing stage. The executing stage runs the plan - goes to disk, loads data, sorts or filters it, goes to disk again for another chunk of data, joins datasets, and so on until the plan is completed and the result is ready to be sent to a customer. These operations usually take up most of the total query time. Plans of executions Let’s find out what happens to the sample query: SELECT u.id, u.last_login, ud.phone
FROM user u
JOIN user_detail ud ON ud.user_id = u.id
WHERE u.firstname = 'John'; From the software perspective Let’s write some plans to run such a query. For example: The direct way should be the best in most cases. for (User u: Users) {
  if (u.firstname == 'John') {
    for (UserDetail ud: UserDetails) {
      if (ud.user_id = u.id) {
        result.put(u.id, u.last_login, ud.phone);
      }
    }
  }
}
return result; If we know that almost all users are “Johns” and just a small part of them have extension the following code should work faster. user_detail for (UserDetail ud: UserDetails) {
  for (User u: Users) {
    if (ud.user_id = u.id && u.firstname == 'John') {
      result.put(u.id, u.last_login, ud.phone)
    }
  }
}
return result; Additional data Indexes. They work as additional structures and in terms of code. The indexes usually look like pre-calculated maps, usually TreeMaps. Let’s for example take the first plan. Some map can be recalculated on each change of the table and that structure can speed up our select-request pretty much. user_id to UserDetails Using index over in UserDetails user_id for (User u: Users) {
  if (u.firstname == 'John') {
    result.put(u.id, u.last_login, user_id_to_UserDetails[u.id].phone);
  }
}
return result; Using index over in User. Since is not unique value this index works as a . firstname firstname MultiValuedMap for (User u: firstname_to_User['John']) {
  for (UserDetail ud: UserDetails) {
    if (ud.user_id = u.id) {
      result.put(u.id, u.last_login, ud.phone);
    }
  }
}
return result; Using both indexes for (User u: firstname_to_User['John']) {
  result.put(u.id, u.last_login, user_id_to_UserDetails[u.id].phone);
}
return result; So, we have plenty of plans. How do we choose the best one? Initially, looks like the latest plan could be the best choice. But it is not true in every situation. Let’s find out why. Statistics and hardware data. The database has already completed several queries on the table and it knows the amount of data and some other things, like how and where the data is stored. The database also knows how and where additional structures (indexes) are stored. After all, each plan has its own complexity. The complexity also depends on additional structures because some useful things can be precalculated. The final timing (or cost) of running depends on the speed of the hardware. This depends not only on the amount of data or requests that should be done to retrieve data but also on the nature of the requests. They can generate both sequential and random reads. And the nature of the queries can greatly affect the final timing. Executing a query To select the best plan, the database should have: the plans themselves; knowledge of pre-calculated things such as indexes or caches from earlier queries; knowledge of the location of data and the additional structures (disc or memory cache); knowledge of the disc and memory work (speed of sequential and arbitrary access, number of IO operations per second). All this helps databases choose an optimal plan to run. Moreover, the best plan can be changed during the database’s lifetime as the table itself changes. At one point the table can fit in memory entirely, at the next - it won't. At one point the index can fit completely in memory, at the next - it won’t. In some cases, the data occupies less space than the indexes themselves. The good news is that we needn’t go too far into the timing of our request. All we have to do is predict the most obvious scenarios for our plan. Searching for the best scenario Each table can be obtained from a disc with some filters in two ways: by full scan. DB loads all entities of the table, iterates through them, and filters them. This method usually generates consecutive reads in storage; by index. DB loads an index, searches for necessary places in the index, then loads only requested rows for further processing. This method usually generates random reads in storage. Let’s compare both approaches with an example To get the rows of the table by : firstname ='John' If there are no indexes by , the database: firstname loads the entire table (all records). The operation requires sequence reads on the disc system and the count of operations fully depends on the table size; filters all entries by fields; sends a result to the client. If there is an index by , the database: firstname searches by index and receives positions in which there are entries with firstname=’John’. The operation requires a few random read requests to the disc and depends on index size and rows count but since it is only logarithmic complexity, it isn’t too many requests, usually just a few; uploads records one by one directly to their positions; sends a result to the client. To access the timing of these approaches, we must know the specifications of the disk system and the size of tables and indexes. For example, let’s take some characteristics of the HDD disk up to 500MB/s for consecutive reading and up to 300 operations per second for random reading. Assume we have 1 million rows and each averages 50 bytes. This means that we have a table size of ~50 Mb and 6-7 Mb of index size (provided we have an average of 6 characters per first name). Assume we have ~300 different Johns in the table. So, to calculate the timings of both approaches: with no indexes, we must read 50 Mb from the disc and filter it by CPU. Reading is much slower than the CPU, so it will take 99%+ of time. So this approach will cost us 50 / 500 = 0.1 sec with the index we need to read the pointers of all records with firstname=’John’ for several reads. Then we need to do up to 3000 random reads from the disc to extract line by line all required rows. Some of them could be on the same page of memory so the actual timing could be lower. But for high assumption, it is 300 reads. 300 ops/sec  / 300 ops = 1 sec. This means that the second approach takes up to one second to complete. It highlights that a database doesn’t always need an index, in some cases a fullscan of the whole table is just more efficient. It also represents in general how databases make assumptions about implementation plans and how they choose the best of them. Other optimizations Actually, databases have different tools to speed up queries. But in the end, all of them work over the disc and memory system trying to reduce operations over the disc system or move them to the memory. For example, when query can use a few indexes over the same data the database can do it with a bitmap operation. It is an operation in which a database loads two or more indexes at the same time. It then performs logical operations over them - for operation and for operation . Then, the database can load the table using result operation over indexes. union OR intersection AND So in that case the whole operation requires fewer and smaller disc reads, some operations on the CPU, and random reads from the disk to sample table rows. Having knowledge about typical internal db operations helps developers not only estimate queries but also choose the correct set of indexes and write faster queries. Conclusion One important modern thing about assumptions is that today we use clouds everywhere and sometimes it is just difficult to find out about hardware in the depth of the cloud provider, and, after all, can be difficult to do an assumption. Nevertheless, there are laws of physics that we cannot circumvent. Each reading requires some time and each operation has a delay. And if you do not have terabytes of memory in your database setup, there is sufficient knowledge to make certain assumptions based on typical queries.

How to Make Rough Estimates of SQL Queries

Today Vercel and with it their highly requested feature — on-demand Incremental Static Regeneration (ISR)! Many thanks to Vercel for sharing a preview of ISR with us, and featuring us in their announcement post! launched Next.js 12.1 With on-demand ISR you can now build real-time static websites. The websites are dynamic and they change in real time, though they are statically generated in the background. So you get both ultra-fast page loads and global distribution. How does it work, and how does it relate to Six? Read on for more information and a . fun example Special thanks to our awesome customer , for building the examples used in this post! Clerk helps Next.js developers add sign-up, sign-in, and user profile management to their applications in minutes. Clerk What is Svix? Svix is an enterprise-ready webhooks service. Sending webhooks requires a lot of engineering time, resources, and ongoing maintenance. Svix lets you build a state-of-the-art webhooks solution in minutes so you can focus on your business. We power the webhooks for , and we've also recently open-sourced . many amazing companies our webhooks dispatcher What is Incremental Static Regeneration (ISR)? Next.js allows you to create or update static pages after you've built your site. Incremental Static Regeneration (ISR) enables developers and content editors to use static generation on a per-page basis, without needing to rebuild the entire site. With ISR, you can retain the benefits of static while scaling to millions of pages. Static pages can be generated at runtime (on-demand) instead of at build-time with ISR. Using analytics, A/B testing, or other metrics, you are equipped with the flexibility to make your trade-off on build times. Does the above look familiar? It's because it's from the wonderful . Please check them out for more information. Vercel docs What is on-demand ISR? ISR is already great and is used by many companies to drastically improve their build times while retaining incredible performance. However, the current interval-based re-validations have proved insufficient for some use cases. Next.js 12.1 (released today) has introduced on-demand ISR which gives developers the flexibility to manually purge the Next.js cache for a page on-demand. It's exciting for a variety of reasons and uses cases. One thing that it enables that is especially cool is building real dynamic websites with statically generated website performance. You no longer need dynamic routes to have dynamic pages. You can now, in real-time, trigger page rebuilds so that they show the most up-to-date data as it changes. Building the real-time guestbook Webhooks are one of the best ways to trigger on-demand ISRs, so using Svix with on-demand ISR is a natural fit. We are going to build a real-time guestbook. Visitors of this website will be able to signup and create their user profile. The website will then list all of the recently signed-up users (in real-time!). Users will also have their profile page that they can edit and share with others. I know it sounds like a lot because it is. Though using Vercel (deployment), Next.js (On-Demand ISR), Svix (webhooks), and one of our customers, (user profile management and authentication), it's going to be a breeze. Clerk You can try out the and continue reading about how it was built. live example The first step would be to build our website's main UI. We would need a nice description explaining what this website does, a signup button, and a list of users. This is what the code to fetch the list of customers looks like: // pages/index.js

import Head from 'next/head'
import Image from 'next/image'
import { SignUpButton } from '@clerk/nextjs'
import clerk from '@clerk/clerk-sdk-node'

export async function getStaticProps(context) {
  const users = (
    await clerk.users.getUserList({
      orderBy: '-created_at',
      limit: 10,
    })
  ).map((u) => ({
    id: u.id,
    firstName: u.firstName,
    lastName: u.lastName,
    profileImageUrl: u.profileImageUrl,
    createdAt: u.createdAt,
  }))
  return {
    props: { users }, // will be passed to the page component as props
  }
}

export default function Home({ users }) {
  // ...
} Though remember, we haven't added ISR yet, so the list of customers was generated at build time and will remain static until the next build. Let's make it dynamic! The next step would be to implement the new on-demand trigger every time a user signs up. We'll create an API route in our Next.js app to add a webhook receiver: // pages/api/revalidate.js

import { Webhook } from 'svix'
import { buffer } from 'micro'

export const config = {
  api: {
    bodyParser: false,
  },
}

export default async function handler(req, res) {
  // Check for secret to confirm this is a valid request
  const payload = (await buffer(req)).toString()
  const headers = req.headers

  const wh = new Webhook(process.env.SVIX_SECRET)
  let msg
  try {
    msg = wh.verify(payload, headers)
  } catch (err) {
    res.status(500).json({ error: 'Webhook verification failed' })
  }

  try {
    // Rebuild the homepage to update the recent sign ups
    await res.unstable_revalidate('/')
    return res.json({ revalidated: true })
  } catch (err) {
    // If there was an error, Next.js will continue
    // to show the last successfully generated page
    res.status(500).json({ error: 'Revalidation failed' })
  }
} In the code snippet above, we are using the to verify that the webhook was indeed sent from Svix and wasn't maliciously triggered by anyone else. Svix JavaScript library Now we need to trigger it so that the ISR regenerates the page. To do that we'll head over to the Clerk dashboard, and click on the Svix webhooks configuration to add our webhook endpoint. We'll want to set the URL to and listen to the and event types. https://svix-vercel-revalidation.clerk.app/api/revalidate user.created user.deleted We now need to set the environment variable to the secret we get from Svix, and that's it! We've built a real-time statically generated website using Vercel, Next.js, Svix, and Clerk. SVIX_SECRET Let's recap how this whole thing works together. We first build a Next.js application and then deploy it on Vercel. We then go to the Svix section on the Clerk dashboard and add our webhook. With the webhook set, every user creation or deletion on Clerk will trigger a webhook to Vercel, which will in turn trigger the ISR regeneration and rebuild the page. It's that simple! In case you missed it above, you can try it out here: , and view the . https://svix-vercel-revalidation.clerk.app/ source code on Github Closing words We had a lot of fun building this with Vercel and Clerk, and it shows how much you can achieve (and with what performance!) by combining a few cool services. If you want your customers to be able to build workflows and automation on top of your service, like the one you saw in this post, you should . give Svix a try This is it for this update, but make sure to follow us on , , or for the latest updates for the , or join the discussion on . Twitter GitHub RSS Svix webhook service our community Slack Also Published here

Build a Guestbook App Using Next.js ISR Feature and Webhooks

I love . Laravel As a PHP developer with a history of working in everything from WordPress to CodeIgniter, when Laravel came on the scene it was a revelation. From the design to the usability, it is an absolutely top-notch framework that contains untold depths of power. That said, sometimes Laravel's own opinionated structure can get in the way of what can feel like pretty simple intentions, such as adding custom global arguments to all Artisan commands. What do I mean by "custom global arguments?" As an example, Artisan commands have the all same set of arguments and options that can be used during runtime: --raw             To output raw command list
    --format=FORMAT   The output format (txt, xml, json, or md) [default: "txt"]
    --short           To skip describing commands' arguments
-h, --help            Display help for the given command. When no command is given display help for the list command
-q, --quiet           Do not output any message
-V, --version         Display this application version
    --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
-n, --no-interaction  Do not ask any interactive question
    --env[=ENV]       The environment the command should run under
-v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug But, what if we wanted to add options and arguments? our own A Wild Problem Has Appeared! I've always been a pretty big fan of for both its power and ease-of-use—okay, maybe not so much lately thanks to how poorly they've communicated their most recent , but I've been a fan. Heroku security incident historically One of Heroku's most frustrating drawbacks, though, is how limited the Scheduler is. A kind of half-assed cron, allows you to run any command on 10-minute, 1-hour, or 1-day intervals, which is useful, but also woefully insufficient for many different types of jobs. Heroku's Scheduler kind of What if I only need something run weekly, monthly, or even yearly? Scheduler says "no." So, in order to work around this (within a typical Laravel application), I have traditionally added an additional argument to my Artisan commands that limits running on specific days. For example: php artisan run:command --day=friday Pretty simple design, right? It gets the job done, but it's hardly scalable. Copying the same several lines of " " logic can get pretty tedious (not to mention nothing close to DRY), so I dug into Artisan to better understand how I could add additional global parameters that can be applied to commands, rather than just the ones I specify. if current day == --day parameter, then run, otherwise return 0 all Extending Artisan Thankfully Laravel, being the object-oriented framework that it is, is pretty easy to extend. The challenge isn't so much in the extension as it is in properly writing said extension up into the rest of the application. That said, before we can actually wire up, we first need to extend the class and add our own custom argument. To do this, create a new file called and paste the following code in: anything Console\Application --day ./app/Console/Application.php <?php
namespace App\Console;

use Illuminate\Console\Application as Artisan;
use Illuminate\Support\Str;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;

class Application extends Artisan
{
    /**
     * Runs the current application.
     *
     * @return int 0 if everything went fine, or an error code
     */
    public function doRun(InputInterface $input, OutputInterface $output)
    {
      if ( !$this->checkDay($input) ) {
        $output->writeln(sprintf('<comment>This command can only be run on %s.</comment>', Str::plural(ucfirst($input->getParameterOption('--day')))), OutputInterface::VERBOSITY_QUIET);

        return 0;
      }

      return parent::doRun($input, $output);
    }

    protected function getDefaultInputDefinition()
    {
        $definition = parent::getDefaultInputDefinition();

        $definition->addOption(new InputOption('--day', null, InputOption::VALUE_OPTIONAL, "Only run the command on the specified day of the week"));

        return $definition;
    }

    public function checkDay(InputInterface $input)
    {
      $day = $input->getParameterOption('--day');

      if ( !$day ) {
        return true;
      }

      return strtolower(now()->englishDayOfWeek) === strtolower($day);
    }
} What the above code is doing can be broken down into a few parts: It creates a new method that gets our custom global parameter ( ) and checks the value against the current day of the week. If the two values are matched (or is not provided), then will return , otherwise it will return . checkDay() --day --day checkDay() true false It extends the method and checks the value of before running the rest of the command. If returns false, the command will immediately and print a comment indicating that the command can only be run on the specified day. doRun() checkDay() checkDay() return 0 Finally, because we want anyone that types to this new argument, we extend and add a new definition indicating that both , and how it works. php artisan --help know about getDefaultInputFunction() --day exists Wiring It Up So, we've extended our console application, but if we were to run our new argument won't show up yet. That's because we need to about our new class, otherwise it will load the original class by default. php artisan --help --day tell Laravel Console\Application To do this, open up and add the following function to the class: ./app/Console/Kernel.php Kernel /**
 * Retrieve the artisan application instance.
 *
 * @return \Illuminate\Console\Application
 */
protected function getArtisan()
{
  if (is_null($this->artisan)) {
    return $this->artisan = (new \App\Console\Application($this->app, $this->events, $this->app->version()))->resolveCommands($this->commands);
  }

  return $this->artisan;
} What the above function does is tell Laravel to load our newly defined class when setting Artisan up, rather than the default class. Because we extended the original class, the existing functionality will still be maintained, but with the new functionality we just added. \App\Console\Application \Illuminate\Console\Application Console\Application Now, if we were to type , we would see a new argument listed in the response: php artisan --help --raw             To output raw command list
    --format=FORMAT   The output format (txt, xml, json, or md) [default: "txt"]
    --short           To skip describing commands' arguments
-h, --help            Display help for the given command. When no command is given display help for the list command
-q, --quiet           Do not output any message
-V, --version         Display this application version
    --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
-n, --no-interaction  Do not ask any interactive question
    --env[=ENV]       The environment the command should run under
    --day[=DAY]       Only run the command on the specified day of the week
-v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug Fin. That's it! All-in-all, it's a pretty straightforward change with some potentially powerful implications. Also published at flower.codes

Extending Laravel Artisan Commands

Software development is a complex task and as a developer you gain nothing from "reinventing the wheel". I'm a firm believer that you should make your life as easy as possible as a developer, by using tried and tested packages where possible; it will take so much headache out of your development experience. Below are a few of the packages that I use in most of my projects. I believe they make for an easier development experience and make my code much easier to maintain. I would recommend that you consider them for your own projects in the future. If I've missed a package that you think is super useful, please share in the comments section below. My top 4 Nuget packages are: Automapper Mediatr Swagger Fluent Validation Automapper Most software applications consist of different layers that each have their own concerns. For example, a common pattern is the . Since each layer has its own concerns and should be loosely coupled to the other layers, each layer normally has its own objects models too. 3-layered data access, logic, and presentation model For example, a user object in the logic layer may contain methods that define the behaviour of that model, whereas a user object in the presentation layer may only contain the properties necessary to be displayed in the UI. Therefore, each time data is passed up and down between layers, the objects of one layer must be converted to the objects of the next layer. For example, in an ASP.NET Core MVC application, you may typically see something like this in a controller action. : { IUserService _userService; {
        _userService = userService;
    } { domainUser = _userService.Get(id); presentationUser = PresentationUser
        {
            Id = domainUser.Id,
            FirstName = domainUser.FirstName,
            LastName = domainUser.LastName, }; JsonResult(presentationUser);
    }
} public class UserController Controller private readonly ( ) public UserController IUserService userService Task<IActionResult> ( ) public async GetUser id int var await var new // etc return new This process is known as mapping, and I'm sure you'll agree that it can get incredibly boring and tedious to write such code, not to mention it convoluting your code with trivial procedures. This is where comes to save the day (and your sanity). It is a convention-based object-object mapper written by and it really takes a lot of the pain out of mapping objects. It really takes minimal configuration in most cases and results in much cleaner code with all of the trivial mapping code removed: Automapper Jimmy Bogard : { IUserService _userService; IMapper _mapper; {
        _userService = userService;
        _mapper = mapper;
    } { domainUser = _userService.Get(id); presentationUser = _mapper.Map<PresentationUser>(domainUser); JsonResult(presentationUser);
    }
} public class UserController Controller private readonly private readonly ( ) public UserController IUserService userService, IMapper mapper Task<IActionResult> ( ) public async GetUser id int var await var return new To find out more, and . read the Automapper documentation find it in the NuGet Gallery Mediatr Mediatr is another package by and is an implementation of the . The mediator pattern is designed to reduced coupled between classes by having them interact through an intermediate mediator class. The result is easier-to-maintain code with fewer dependencies. Jimmy Bogard mediator software design pattern All interactions in Mediatr consist of a class containing the data that you want to send and a handler class for that data. There are two different types of interaction, a request and a notification. A request expects to have just one handler implementation and can expect a value to be returned from the request. : < >
{ UserId { ; ; }
} : < , >
{ IUserService _userService; {
        _userService = userService;
    } { _userService.Get(request.UserId);
    }
} : { IMediator _mediator; {
        _mediator = mediator;
    } { request = UserRequest { UserId = id }; user = _mediator.Send(request); JsonResult(user);
    }
} public class UserRequest IRequest DomainUser public int get set public class UserRequestHandler IRequestHandler UserRequest User private readonly ( ) public UserRequestHandler IUserService userService Task<User> ( ) public async Handle UserRequest request, CancellationToken ct return await public class UserController Controller private readonly ( ) public UserController IMediator mediator Task<IActionResult> ( ) public async GetUser id int var new var await return new A notification is similar to an event. It can be broadcast to multiple handlers, each of which can do their own logic based on the notification. Notifications do not return any value. : { UserId { ; ; }
} : < >
{ { }
} : < >
{ { }
} : { IMediator _mediator; {
        _mediator = mediator;
    } { request = UserRequest { UserId = id }; user = _mediator.Send(request); notification = UserRetrievedNotification { UserId = id }; _mediator.Publish(notification); JsonResult(user);
    }
} public class UserRetrievedNotification INotification public int get set public class UserRetrievedNotificationHandler1 INotificationHandler UserRetrievedNotification Task ( ) public async Handle UserRetrievedNotification notification, CancellationToken ct // do some logic public class UserRetrievedNotificationHandler2 INotificationHandler UserRetrievedNotification Task ( ) public async Handle UserRetrievedNotification notification, CancellationToken ct // do some more logic public class UserController Controller private readonly ( ) public UserController IMediator mediator Task<IActionResult> ( ) public async GetUser id int var new var await var new await return new Another really cool feature of Mediatr is that you can configure a pipeline to actions to run before and after a request/notification, so you could implement exception handling or logging automatically for every request. To find out more, and . read the Mediatr documentation find it in the NuGet Gallery Swagger Swagger is a must-have if you're creating APIs using ASP.NET Core. It automatically scans all of your controllers and actions to generate an , which makes it super easy to visualise and maintain all of your API endpoints. OpenAPI document Swagger is also really useful for testing as it allows you to send requests to each of your endpoints via the browser. There's not really much more to say than that, since it requires hardly any configuration and generates everything for you. For instructions on how to install it, I would recommend . To find out more, and . this Microsoft article read the Swagger documentation find it in the NuGet Gallery Fluent Validation When receiving any input from a user, it is important to make sure that the data that they have supplied is valid and complete. You can do this to some extent on the front end using (and you definitely should do this for a better user experience), but all input should be validated again on the backend since there are a number of ways that a user could bypass the client-side validation (whether maliciously or not). client-side form validation There are a number of ways that you could set up validation on the server, but ultimately it comes down to checking each property of the input class against a set of rules. The logic for these rules will need to be defined for each input class, and, similar to the object mapping example, can be rather boring, repetitive and trivial. : { IUserService _userService; {
        _userService = userService;
    } { (user ) ArgumentNullException(); ( .IsNullOrEmpty(user.FirstName)) ArgumentException(); (user.FirstName.Length > ) ArgumentException(); result = _userService.Create(user); JsonResult(result);
    }
} public class UserController Controller private readonly ( ) public UserController IUserService userService Task<IActionResult> ( ) public async CreateUser User user if is null throw new if string throw new if 50 throw new // etc var await return new Fluent Validation makes this whole process much more pleasant by using a to configure validation in a much less tedious way. The logic for many common types of validation is already defined, along with helpful error messages, although this can all by configured further if you wish. fluent interface pattern : < >
{ {
        RuleFor(u => u.FirstName).NotEmpty().MaximumLength( );
        RuleFor(u => u.LastName).NotEmpty().MaximumLength( ); }
} public class UserValidator AbstractValidator User ( ) public UserValidator 50 50 // etc To find out more, and . read the Fluent Validation documentation find it in the NuGet Gallery Conclusion These were my top 4 Nuget packages that I use in almost all of my projects. I find that they make for a much nicer development and maintenance experience, and I hope that you will find them useful too. If you know any other packages that you think should have been in this list, please let me know in the comments section below. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also . subscribe to my newsletter find me on Twitter Previously published at https://samwalpole.com/my-top-4-nuget-packages-for-aspnet-core

The Top 4 Nuget Packages According to This Software Developer

Hi folks !! In this post, i will talk about how to design a quick relational database schema and how to write a raw sql query in relational database . So, without wasting time lets get started. Before delving into designing a schema, lets look at the properties that makes a good Database . ACID Properties of a transaction in a db . tomic : Each transaction is treated as a single unit, which either succeeds completely, or fails completely. A onsistent : DB is consistent before and after the transaction. C solated : Transactions occur independently without interference. means reading and writing to multiple tables at the same time. I urability : Durable in crashes and is fault tolerant . means once a transaction has been committed, it will remain committed even in the case of a system failure. D Designing DB Schema I am already assuming that you have choose to opt for a relational DB like (sql , postgres etc ..) as your primary source of information for your application . You can mix and match too (which is a typical case for almost every application) but that’s beyond the scope of this post . I am also assuming that you have fair knowledge of keys and indexes in databases.( If not, please don’t write anything about it in the comments section). Note : A database schema is the skeleton structure that represents the logical view of the entire database. It can simply be called as a metadata that describes the relationships between objects and information in a database. In order to develop a good Relational DB schema, you only need to know 2 things . 1. Type of relationship between entities 2 . Normalisation in DB (1NF , 2NF , 3NF) Types of relationship : Type of relationship between entities will tell you about the number of tables you are required to make in your DB . A DB can have multiple tables . There are three types of relationship in general . Lets look at it closely — One to One A. In a one-to-one relationship, one record/row in a table is associated with one and only one record/row in another table. B. Both tables will have same Primary Key that will be used to identify the record/row . We will get the complete data from both the tables by performing a join on this primary key . C. Example : User table (split it into primary details and secondary details of a user ) Table 1: (Primary Info): User_ID (primary key), First name , Last name Table 2: (Secondary Info): User_ID(primary key), address,email,contact etc.. Note: You can argue about putting all the data in same table with just 1 primary key but Trust me, it will not be an efficient and a good db design with million values. One to Many A. In one-to-many relationship, each record in Table A may have many linked records/row in Table B, but each record/row in Table B may have only one corresponding record/row in Table A. B. In order to get data, simply put the primary key of table 1 as the foreign key of the 2nd table. You need minimum 2 table in order to design a good 1 to many relationship. C. Example : Storing information of all Political Party Candidates. In this, Many Candidates belong to the same party . They cannot represent multiple parties at same time . Table 1: (Political Party Info): Political_Party_ID (Primary key) , Party_Name , Political_Party_Head Table 2: (Party Candidates Info): Candidate_ID (Primary key), Candidate_Name , Political_Party_ID(Foreign key as reference from Table 1) Many To Many A. A many to many relationship occurs when multiple records in a table are associated with multiple records in another table. B. Relational database systems usually don’t allow you to implement a direct many-to-many relationship between two tables. So, you are required to create a third table for this relationship . This is the most common relationship that you will see in almost every application . The 3rd table is called a link table or a junction table. You can query on the third table directly in order to get data for analysis purposes . C. Example: Students enrolled in different courses in High School. Many/Multiple students can enrol in many/Multiple courses and many/Multiple courses can be opted by multiple/Many Students. Table 1 : (Students Info ) : Student_ID (Primary Key) , Student_Name etc. Table 2 : (Courses Table): Course_ID (Primary key) , Course_Name, Cost etc. Table 3 : (Enrollments Table): [ Student_ID (Foreign Key as Reference from Students Info ),Course_ID (Foreign Key as reference from Courses Table) ] —{ Composite Key } , Enrollment_ID etc .. Note: Here, Table 3 will have a composite key which is a mix of foreign keys from table 1 and table 2 and this composite key will act as a primary key of this junction / Link table . ormalization N It is the process of minimizing redundancy from a relation or set of relations in DB . 1 NF — There has to be a key that uniquely identifies a record/ row . This is generally a primary key or composite key . (concept of primary key ) 2 NF — should be in 1 NF and every non-key column should be fully dependent on the primary key. ( concept of foreign key ) 3 NF — it should be in 2-NF and Non key columns are independent of each other . if they do depend, then you would probabily have to split the table. Writing Raw SQL Query Lets look at some basic patterns to query a database. Remember — Result of a query is always a table . Pattern 1 SELECT * FROM WHERE Here, * means all columns and condition can be used to match the value in a database row . * can be change into the column values required to get from table . TABLE_NAME CONDITION/RESTRICTION : Ex: SELECT FIRST_NAME , LAST_NAME FROM USERS WHERE USER_ID =1 Ex: SELECT COUNT(*) FROM USERS_TABLE WHERE PURCHASE_DATE > 12–12–2018 AND < 12–1–2019 Ex: SELECT NAME FROM USERS_TABLE WHERE NOT( AGE = 20 ) AND NOT(FIRST_NAME = ‘KARAN’) Ex: INSERT INTO USERS_TABLE VALUES (‘KARAN ’,’JAGOTA’ ) There are some other functions/clauses that you can use in this pattern. It includes — limit value offset value or group by col_name or order by column_name desc or count(*) as total or having col_name = value (having happens after the ‘WHERE’ whereas group_by or order_by are done before ‘WHERE’) . Pattern 2 SELECT , FROM JOIN ON = OBJECT_OF_TABLE_1.COL OBJECT_OF_TABLE_2.COL TABLE_1 TABLE_2 OBJECT_OF_TABLE_1.COMMON_KEY OBJECT_OF_TABLE_2.COMMON_KEY Here, you create an object(use any variable name. like — i am using U and P in the example for users and orders table) for both the tables , select the column name that you want and join them(inner join / left join/right join) by table name on their common key (primary key of one table with foreign key of the other table) Ex: SELECT U.FIRST_NAME , P.PURCHASE FROM USERS_TABLE JOIN ORDERS_TABLE ON U.CUSTOMER_ID = P.CUSTOMER_ID Pattern 3 SELECT FROM ( ) AS AVG(*) SUBQUERY ALIAS Here, you are simply writing a query within query .As we know that the result of a query is a table itself , it can be used to further query and find the result/data that is needed . I hope you liked my post. Please, give it a clap !! and if you are new to programming, you can also check out my post on pythonic way of doing things and JavaScript Essentials by clicking on the link below . Pythonic Way Of Doing Things JavaScript Essentials (concepts + code) for frontend and backend developers Don’t forget to clap, share and follow.

Relational Databases (Designing Schema & Writing a Query)

Pretty sure that you’ve already familiar with Dependency Injection (DI) design pattern and with types of dependency injections: constructor, setter, interface. Also in some sources, you can find parameter dependency injection type.In this topic you’ll find yet another type of DI — namespace! Prerequisites I expect you already familiar with idea behind DI and you have clear understanding why do you need this. If not — please read basic information about DI first. Let’s assume that our application is Ukrainian 🇺🇦 VISA center which can provide, approve or decline VISA to any country in the world, for simplicity will consider only the European Union here. First of all, we need interface,file : src/Domain/Interfaces/VISA/EuropeanUnion.php Now we have implementation for non-visa-free case (let’s call this case “review”), file : src/Infrastructure/VISA/Review/EuropeanUnion.php And another one implementation for VISA-FREE case,file : src/Infrastructure/VISA/Free/EuropeanUnion.php Target The main aim — is to have somewhere (for example in file )super simple code like this: index.php Solution Use namespace Dependency Injection and configure your file: composer.json and run: (it’s important, please don’t forget run this command). php composer dump-autoload Test Now just run command: and you’ll see: php index.php 'You have to provide documents for review.' Now please update with next content: composer.json and run: and run: you’ll see: php composer dump-autoload php index.php 'Your request is approved!' That’s it! Congrats! Comparison with other approaches Alternatives: Factory Method (or even Abstract Factory), constructor or setter Dependency Injection or Strategy designs patterns. Yes, these patterns can be considered as an alternative, but all of them require you to write technical code like: class Factory{public static function create($name){if (class_exists($name)) {return new $name();}}} or public static function getInstance(string $name){if (!isset(self::$instances[$name])) {$className = "App\\Infrastructure\\" . ucfirst($name);if (!class_exists($className)) {throw new RuntimeException("Unknown class: $className");}self::$instances[$name] = new $className();}return self::$instances[$name];} also in the real-world project, it’ll look more sophisticated, maybe . Also you’ll mix your declarative style code with something like: like this $name = ($parameter === 'free') ? 'VISA/Free' : 'VISA/Review';$visa = Factory::create($name);// and only now$visa->approve(); And also in case of using these patterns you have to have all code in one place (one repo), but imagine that and may be huge subsystems with own factories, strategies, microservices, internal business logic implementations etc — it may turn out to be nightmare. VISA/Review VISA/Free With Namespace Dependency Injection you can create dedicated packages (repos) for interfaces, , etc. Every package only has to know about interfaces, no more. So it’s more flexible, easier to maintain, extend and re-use!You can even have separated development teams for every package, if you have really huge project. VISA/Review VISA/Free And most important — on application level you‘ll have super simple code in and all internal details won’t confuse you. Your project will be more predictable because behavior won’t vary at runtime depending on different circumstances, it’ll work strictly accordingly to your configuration.And also as a bonus, IDE (like PHPStorm) will help you more, because it won’t scream on code like: . declarative style new $className(); Performance comparison Namespace DI is that all other types of dependency injections!!! Because this approach has no configs or infrastructural stuff mentioned earlier or or something else…, hence in this way PHP won’t waste time executing redundant code during each http request! faster yaml DI Container Why this approach not popular Because this type of dependency injection possible only in PHP due to the way how autoloading works. It’s impossible to do the same event in JavaScript, no use to speak about other languages. As result — this technic not wide spread. With other types of dependency injections it’s possible to change application behavior at runtime, but with Namespace DI — it’s impossible. Conclusion In case you don’t need to change behavior (or internal implementation) of your application at runtime but need to have opportunity to change it from config file (even ), plus reduce execution time— you can consider as an option Namespace Dependency Injection! composer.json

Namespace Dependency Injection in PHP

Many are wondering whether Golang is a language that can apply the Object Oriented Programming paradigm. Let's discuss this here. First of all, we have to know what is meant by Object-Oriented Programming, after that we will try to answer the question of whether GO can implement Object-Oriented Programming. Object-Oriented Programming (OOP) By definition Object Oriented Programming means that this paradigm focuses on objects, objects in a language are made of classes or entities. So by definition, Object-Oriented Programming means an object-focused paradigm.¹ Conceptually, the Object-Oriented Programming paradigm has four main concepts, namely abstraction, encapsulation, inheritance, and polymorphism.² Can GO implement Object-Oriented Programming? Can GO create objects from classes or entities? Let's try to prove it // class or entity or struct
type Person struct {
	// attributes
	FirstName string
	LastName  string
}

// method
func (p *Person) fullname() string {
	return p.FirstName + " " + p.LastName
}

func main() {
	john := Person{
		FirstName: "John",
		LastName:  "Travolta",
	}

	fmt.Println(john.fullname()) // John Travolta

} The answer is yes, in GO we can create an Object from a class/entity, a class in GO is also called a lightweight struct.³
By definition, GO can apply the Object-Oriented Programming paradigm. What about the main concept of Object-Oriented Programming? This question has caused a lot of debate on "which GO language can implement Object-Oriented Programming or not". Let's discuss the concepts one by one. Abstraction Abstraction is a concept that allows us to hide complexity in the implementation, and only provide information that the user needs or uses. For example, we will create two employee abstractions that will be used by the payroll department and employee managers. The payroll section requires the name and amount of the salary, so the employee abstraction in the payroll package contains only the function which returns how much salary to use. we hide the difficulty of calculating salaries, calculating bonuses, and . GetName CalculateSalary how performance affects bonuses is not required by payroll package payroll

// employee abstraction on finance
type EmployeeOnPayroll interface {
	GetName() string
	CalculateSalary() float64
}

func Work(employees ...EmployeeOnPayroll) {
	for _, employee := range employees {
		fmt.Println(employee.GetName(), "salary is", employee.CalculateSalary())
	}
} Likewise, the manager only needs a function to assess performance, so the employee abstraction on the manager's side only contains the function, . SetPerformance no other functions such as CalculateSalary are needed package manager

// employee abstraction on manager 
type EmployeeOnManager interface {
	SetPerformance(performance employee.Performance)
}

func Work(employees ...EmployeeOnManager) {
	for i, employee := range employees {
		employee.SetPerformance(employee.Performance(i % 3))
	}
} In our package, the implementation, and all the hassle of calculating salaries and bonuses are . employee hidden from other packages package employee

// performance constant
type Performance int32
const (
	Bad Performance = iota
	Good
	Great
)

type Employee struct {
	// attributes
	Name        string
	BasicSalary float64
	performance Performance
}

// employee method
func (e *Employee) GetName() string {
	return e.Name
}

func (e *Employee) SetPerformance(performance Performance) {
	e.performance = performance
}

func (e *Employee) CalculateSalary() float64 {
	salary := e.BasicSalary
	salary += e.calculateBonus()
	/*
		Do more calculation
	*/
	return salary
}

func (e *Employee) calculateBonus() float64 {
	switch e.performance {
	case Great:
		return e.BasicSalary
	case Good:
		return e.BasicSalary / 2
	default:
		return 0
	}
} In the main package, we can see how the abstraction we have created works. package main

/*
imports ...
*/

func main() {
	john := &employee.Employee{Name: "John", BasicSalary: 3000}
	jane := &employee.Employee{Name: "Jane", BasicSalary: 2000}
	bane := &employee.Employee{Name: "Bane", BasicSalary: 1500}
	manager.Work(john, jane, bane)
	payroll.Work(john, jane, bane)
	/*
	  John salary is 3000
	  Jane salary is 3000
	  Bane salary is 3000
	*/
} Even though John, Jane, and Bane have different base salaries but because of the performance bonus, in the end, they get the same salary. Encapsulation Encapsulation is the concept of how we can protect data or functions on an entity, thus avoiding the wrong use or unwanted data changes. Applying Encapsulation to Golang is quite easy, the use of lowercase in the first letter of naming attributes and methods indicates that the methods and attributes are private (cannot be accessed from outside the package).
For example, we can see the attribute (line 15) and the method (line 36) in the employee package. performance calculateBonus package employee

// performance constant
type Performance int32
const (
	Bad Performance = iota
	Good
	Great
)

type Employee struct {
	// attributes
	Name        string
	BasicSalary float64
	performance Performance // performance is private attribute
}

// employee method
func (e *Employee) GetName() string {
	return e.Name
}

func (e *Employee) SetPerformance(performance Performance) {
	e.performance = performance
}

func (e *Employee) CalculateSalary() float64 {
	salary := e.BasicSalary
	salary += e.calculateBonus()
	/*
		Do more calculation
	*/
	return salary
}

func (e *Employee) calculateBonus() float64 { // caculateBonus is private method
	switch e.performance {
	case Great:
		return e.BasicSalary
	case Good:
		return e.BasicSalary / 2
	default:
		return 0
	}
} Inheritance Inheritance is a concept where we can inherit methods and attributes from an existing class (parent class) to a newly created class (child class). GO does not have Inheritance, but can use Composition as a solution even though it is still different from Inheritance, if Inheritance we can treat child classes as parent classes, while with Composition in GO we have to create interfaces if we want to use parent classes and child classes in the same place. if you wonder why? you can read an article from Rob Pike or Golang FAQ about inheritance . here here Composition in GO is quite easy to do, just add the base struct (parent class) to the newly created struct attribute. For example in line 4, we combine the struct with the struct.
The Supervisor automatically gets all the methods and attributes of the Employee. Employee Supervisor package employee

type Supervisor struct {
	Employee  // composite Employee to Supervisor
	SupervisorBonus float64
}

// Overriding CalculateSalary function from Employee Struct
func (s *Supervisor) CalculateSalary() float64 {
	salary := s.BasicSalary
	salary += s.calculateBonus()
  
        // add supervisor bonus to salary
	salary += s.SupervisorBonus
	/*
		Do more calculation
	*/
	return salary
} Because it gets all the methods and attributes of the , the can be directly used in the and interfaces. Employee Supervisor EmployeeOnManager EmployeeOnPayroll package main

/*
imports ...
*/

func main() {
	john := &employee.Employee{Name: "John", BasicSalary: 3000}
	jane := &employee.Supervisor{
		Employee:        employee.Employee{Name: "Jane", BasicSalary: 2000},
		SupervisorBonus: 500,
	}
	bane := &employee.Employee{Name: "Bane", BasicSalary: 1500}
	manager.Work(john, jane, bane)
	payroll.Work(john, jane, bane)
        /*
          John salary is 3000
          Jane salary is 3500
          Bane salary is 3000
        */
} Polymorphism Polymorphism consists of two words, namely Poly which means many, and Morph which means form. Usually, in Object-Oriented Programming, there are two ways to apply Polymorphism, namely Overloading and Overriding. Overloading allows a class to have methods with the same name but have different parameters or return parameters. Overriding allows the child class to have the same method (name, parameter, and return parameters) as the parent class but with a different implementation, when the method is called, the implementation of the child class will be used. Golang can apply Overriding, but cannot apply Overloading. Why? You can read the explanation in GO FAQ . here The implementation of overriding in GO is similar to Java or Javascript. After we do the composition for the child class we can create a method in the child class with the same name, parameters, and return parameters as the method we want to override. For example, the method on the struct on line 9. The actually already has a method obtained from the struct, but we need to override it because there are different ways of calculating. CalculateSalary Supervisor Supervisor CalculateSalary Employee package employee

type Supervisor struct {
	Employee  // composite Employee to Supervisor
	SupervisorBonus float64
}

// Overriding CalculateSalary function from Employee Struct
func (s *Supervisor) CalculateSalary() float64 {
	salary := s.BasicSalary
	salary += s.calculateBonus()
  
    // add supervisor bonus to salary
	salary += s.SupervisorBonus
	/*
		Do more calculation
	*/
	return salary
} With overriding, Jane's salary calculation result changed from 3000 to 3500, because was added to her salary. SupervisorBonus package main

/*
imports ...
*/

func main() {
	john := &employee.Employee{Name: "John", BasicSalary: 3000}
	jane := &employee.Supervisor{
		Employee:        employee.Employee{Name: "Jane", BasicSalary: 2000},
		SupervisorBonus: 500,
	}
	bane := &employee.Employee{Name: "Bane", BasicSalary: 1500}
	manager.Work(john, jane, bane)
	payroll.Work(john, jane, bane)
        /*
          John salary is 3000
          Jane salary is 3500
          Bane salary is 3000
        */
} Conclusion So is Golang an object-oriented programming language? I will quote two versions of the answer. , GO is Object-Oriented, but in an unusual way.⁴ Yes , although Go has types and methods, and allows "style" Object-Oriented Programming, but GO does not have a hierarchy (inheritance). The GO “interface” concept (because it uses Composition, not Inheritance) provides a different approach that GO's creators believe is easier to use in more general terms.⁵ Yes and No References ¹__ __ ²__ __ ³__ __ ⁴__ __ ⁵__ __ https://www.javatpoint.com/what-is-object-oriented-programming https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/ https://www.geeksforgeeks.org/structure-equality-in-golang/ https://talks.golang.org/2012/chat.slide#5 https://go.dev/doc/faq#Is_Go_an_object-oriented_language Thank you for reading, hopefully, it will be useful for all of us, and we can learn together to be better. If you have questions or want to share or discuss, you can go through the comments column or through my contact on my profile 😁 Also Published here

Does Golang Follow the Object Oriented Programming Paradigm?

1. Destructuring Assignment Destructuring assignment allows one or more object properties to be assigned to variables in a single expression. The created variable will have the same name as the property. let myObj = {
  id: 1,
  name: 'My Object'
};

// without destructuring assignment
let id = myObj.id;
let name = myObj.name; 
// id = 1, name = 'My Object'

// with destructuring assignment
let { id, name } = myObj;
// id = 1, name = 'My Object' This is most useful when you know that you need to use multiple properties from an object, you need to use the same property multiple times, or the property that you wish to use is deeply nested in that object. In all these cases, using destructuring assignment saves you from all the clutter of getting the object properties through chaining and makes your code more concise and easier to read. For example, I have recently been working a lot with , a Javascript framework for building interactive maps. It is highly customizable and allows you to assign your own properties to different markers on the map. However, accessing these properties can get somewhat messy - we can clean this up with destructuring assignment. Leaflet // without destructuring assignment
function onEachFeature (feature, layer) {
  if (feature.properties.hasPopup) {
    let popupContent = `<a href="/feature/${feature.properties.id}">${feature.properties.name}</a>`;
    layer.bindPopup(popupContent);
  }
}

// with destructuring assignment
function onEachFeature (feature, layer) {
  let { hasPopup, id, name } = feature.properties;

  if (hasPopup) {
    let popupContent = `<a href="/feature/${id}">${name}</a>`;
    layer.bindPopup(popupContent);
  }
} We may have added an additional line of code, but I believe this makes it much clearer and easier to read the intention of this function now. It is also possible to destructure arrays, which allows you to assign one or more elements in that array to variables. However, I do not personally find myself using this syntax often so I won’t cover it any further here. If you wish to learn more, please see the . MDN reference Finally, if you are using a function that has an object as a parameter, it is possible to destructure that object within the parameter list. This saves you the effort of having to explicitly declare the variables yourself and makes it clear which properties are required by the function. function logPerson(person) {
  let { name, age } = options;
  
  console.log(`${name} is ${age} years old`);
}

function logPerson({ name, age }) {
  console.log(`${name} is ${age} years old`);
} 2. Short Circuit Evaluation & Assignment The JavaScript logical operators, AND (&&) and OR (||) are known as short circuit operators because they only evaluate the expression as far as necessary in order to determine the result of the boolean expression. For example, AND requires that both sides of the expression evaluate to true. Therefore, if the left-hand side of the expression evaluates to false, it does not bother to check the right-hand side as it would be a waste of time. Similarly, OR requires that only one side of the expression evaluates to true. Therefore, if the left-hand side evaluates to true, it doesn't bother to check the right-hand side. This short-circuiting can be useful for adding some safety to expressions involving objects. For example, consider the following function: function logIfAdult(person) {
  if(person.age >= 18) {
    console.log("Person is an adult");
  }
} The problem with this implementation is that you cannot guarantee that the person object is not null. If you run this function with a null person, you will get the following error: . Uncaught TypeError: Cannot read property 'age' of null Thanks to short circuit evaluation, we can add some safety like this: function logIfAdult(person) {
  if(person && person.age >= 18) {
    console.log("Person is an adult");
  }
} This is because, if person is null it will evaluate to false (this is because null is a "falsey" value, if this concept is new to you, ), and the whole expression will short circuit. Only if person is not null will the expression move on to check the right-hand side of the expression, at which point we know it is safe to check and we wont get any errors. please read this article too We can exploit this short-circuiting when assigning variables too. For example, consider the following function: function logName(person) {
  let name = person && person.name;
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'null' What is happening here? Well in the first example, we pass the function a valid person object. Because the person object is not null, the AND operator moves over to the right-hand side of the expression, and assigns the value of to the name variable. In the second example, person is null so the expression short circuits and returns null to the name variable. person.name We can extend this further to log a default name instead of just null. This time we use the OR operator, so we will only use the default value if the person object is null. function logName(person) {
  let name = person && person.name || 'Default Name';
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'Default Name' 3. Optional Chaining & Nullish Coalescing Operator Short circuit evaluation and assignment is so common that new more concise syntax is being added in to JavaScript to achieve the same aim. These are the optional chaining and nullish coalescing operators. I have decided to include both short-circuiting and optional chaining/null coalescing since, at the time of writing, the latter are newer features and may not be fully compatible with older browsers. The optional chaining operator (?.) allows you to dive into objects without explicitly having to check if the object is not null. If the object is null, then the expression will just return undefined instead of throwing an error. For example, with optional chaining, the logIfAdult function from above can be rewritten as: function logIfAdult(person) {
  if(person?.age >= 18) {
    console.log("Person is an adult");
  }
} The nullish coalescing operator (??) is used to return a default value if the value on the left-hand side of the expression is null. In this way, it replaces the functionality of the OR operator in the logName function above: function logName(person) {
  let name = person?.name ?? 'Default Name';
  console.log(name);
} 4. Named Callback Functions Anonymous functions can be really useful - they can be declared when and where you want, and are great if you only need the function as a one-off. let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let viewModels = people.map(p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
}));
// viewModels = [{ id: 1, name: 'Sam Walpole' }] However, since the function has no name, you are leaving it up to future developers to work out what the code inside your callback function does - that's ok here, but in longer, more complex functions it may waste unnecessary time. By declaring the function first as a named function, you instantly make the code more readable and give future developers some clues as to the intent of the function. let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let toViewModel = p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
});

let viewModels = people.map(toViewModel);
// viewModels = [{ id: 1, name: 'Sam Walpole' }] 5. Enums/Dictionaries An enum is a way to store a set of constant values as a type. Most languages have in-built support for enums, but in JavaScript we have to construct them ourselves using an object. const Color = {
  RED: 'RED',
  GREEN: 'GREEN',
  BLUE: 'BLUE',
};

let redCar = {
  make: 'Ferrari',
  model: '812',
  color: Color.RED,
};

let greenCar = {
  make: 'Aston Martin',
  model: 'Vantage',
  color: Color.GREEN, 
}; Enums pair nicely with switch statements for flow control: function getHexColor(car) {
  switch (car.color) {
    case Color.RED:
      return '#ff0000';
    case Color.GREEN:
      return '#00ff00';
    case Color.BLUE:
      return '#0000ff';
  }
} However, sometimes this can be a bit verbose. Instead of using a switch statement here, we could use a dictionary. Dictionaries in JavaScript are declared in a very similar way to enums, but conceptually they have a different purpose. Where enums are a set of constant values, dictionaries are a collection of key/value pairs. function getHexColor(car) {
  let hexColors= {
    [Color.RED]: '#ff0000',
    [Color.GREEN]: '#00ff00',
    [Color.BLUE]: '#0000ff',
  };

  return hexColors[car.color];
} In the above example, we have got rid of the need for a switch statement, as we have created a dictionary with the enum values as the key, and the hex colors as the values. By removing all the clutter of the switch statement, I believe that this leads to much easier-to-read code. Conclusion In this article, I have provided 5 tips that I regularly use in JavaScript to make my code more concise and easy to read. I hope that you have found them helpful and will find the opportunities to use them in your own code. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also find me on . subscribe to my newsletter Twitter

Write Cleaner Code with My Top 5 JavaScript Hacks 

Data Structures and Algorithms: 20 Problem-Solving Techniques

...for Better Code Separation What is this Model, View, Controller (MVC) architectural pattern? Sources: Rails Documentation The architecture divides your code into three (3) layers , and separating the different responsibilities of the program. MVC Models Views Controllers Image from Wikipedia Model Layer This layer in contains the domain model, which generally represents a specific object class (e.g. a Person, Animal, Books). This is where the is usually handled since this model is linked to the and its data is derived from the relative table’s rows. Ruby on Rails business logic database View Layer Handles the representations of the responses provided by the controllers. Since the controller can return information as HTML, XML, JSON, etc. visual Controller Layer In this layer is responsible for with the , its and providing suitable responses to various requests. Rails interacting model manipulating data HTTP Now, what would this MVC pattern look like in JavaScript? Source: MDN web docs Since generally does not involve the use of databases (although it could), nor HTTP request handling (Once again it could), the pattern will have to be tweaked a bit to fit the language specificity. JavaScript MVC Image from MDN Model Layer The can literally be as simple as an but usually it would be a . An application can have and these classes (models) would contain the needed for the app to function. model layer array class multiple models basic data Take for instance a which tracks which classes a person is taking. The models in this case can be divided into classes such as a Classroom, Person and an Array based model called Subjects. E.G. Classroom App Base Model Classes { (id, subject = 'Homeroom') { .id = id; .persons = []; .subject = subject;
  }
} class Classroom constructor this this this The contains data variables which will hold information for each classroom. This would be a list of all the currently enrolled in this classroom, the associated with this classroom and it's . Classroom model persons subject ID { (id, firstN = 'John', lastN = 'Doe') { .id = id; .firstName = firstN; .lastName = lastN; .subjects = []; .classrooms = [];
  }
} class Person constructor this this this this this The contains data variables which will hold information for each person. This would be their and , the that they are studying and which they are apart of. Person model first last name subjects classrooms subjects = [ , , , , , ]; const "English" "Math" "Computer Science" "Business" "Finance" "Home Economics" The will simply be an array, since for this example I have no intention in allowing the subjects model to be manipulated. Subjects model Controller Layer The controller would be a class which translates the user input into changes to the model's data. In the – the controller receives user input from view elements such as text input or select options and button clicks which is used to modify the model. E.G. Classroom App classroomModel ; { () { .lastID = ; .classrooms = []; .selectedClass = ;
  }

  selectClassroom(classroomID) { .selectedClass = .classrooms
    .filter( c.id === (classroomID, ))[ ];
  }

  addClassroom(subject) { .classrooms.push( classroomModel( .lastID, subject)
      ); .lastID += ;
  }

  removeClassroom(classroomID) { .classrooms = .classrooms
      .filter( c.id !== (classroomID, ));
  }

  setSubject(subject, classroomID) { classroom = .classrooms
      .filter( c.id === (classroomID, ))[ ];
    classroom.subject = subject;
  }

  addPerson(person, classroom) { (!person) ;
    classroom.addPerson(person);
  }

  removePerson(person, classroomID) { classroom = .classrooms
    .filter( c.id === (classroomID, ))[ ];
    classroom.removePerson(person);
  }
} import from "../models/classroom" class ClassroomController constructor this 0 this this null this this => c parseInt 10 0 this new this this 1 this this => c parseInt 10 const this => c parseInt 10 0 // const classroom = this.classrooms // .filter(c => c.id === parseInt(classroomID, 10))[0]; if return const this => c parseInt 10 0 The in this case could be seen as a in reference to how operates and each row in this "Table" would be information linked to each classroom object already created. classroom controller Table Rails This controller has variables of its own, " " (Every time a classroom object is created and added to the classrooms array this variable's value increments), " " (an array of all created classroom objects) and " ". three lastID classrooms selectedClass View Layer This layer handles the representation of the app’s data. This layer contains classes which allows the to see and with the . visual User interact data In the – the view would provide elements such as , and (<div/>, <span/ >, <p/>…etc.) to display the various persons and classrooms and their related data. E.G. Classroom App ( ) Document Object Model DOM Buttons Inputs containers classroomController ; subjects ; { (appDiv) { .classroomController = classroomController(); .classroomSectionDiv = .createElement( ); .classroomsDiv = .createElement( ); .addclassBtn = .createElement( ); .selectSubjectInput = .createElement( ); .classroomSectionDiv.classList.add( ); .classroomsDiv.classList.add( ); .selectSubjectInput.innerHTML = subjects.map( ( )); .addclassBtn.textContent = ; .addclassBtn.addEventListener( , () => .addClassroom()); .classroomSectionDiv.append( .classroomsDiv, .selectSubjectInput, .addclassBtn,
      );
    appDiv.appendChild( .classroomSectionDiv);
  }

  updateView() { { classroomController, classroomsDiv } = ; allClassrooms = classroomController.classrooms.map( { removeBtn = .createElement( ); classDiv = .createElement( );
        classDiv.classList.add( ); (classroomController.selectedClass === c) {
          classDiv.classList.add( );
        }
        classDiv.addEventListener( , () => .selectClassroom(classDiv.getAttribute( )));
        classDiv.setAttribute( , c.id);
        removeBtn.addEventListener( , () => .removeClassroom(removeBtn.getAttribute( )));
        removeBtn.setAttribute( , c.id);
        removeBtn.classList.add( );
        removeBtn.textContent= ; allPersons = c.persons.map( ( ));
        classDiv.innerHTML = ;
        classDiv.appendChild(removeBtn); classDiv;
      }
    );
    classroomsDiv.innerHTML= ;
    allClassrooms.map( classroomsDiv.append(div));
  }
  
  selectClassroom(classroomID) { { classroomController } = ;
    classroomController.selectClassroom(classroomID); .updateView();
  }

  addClassroom() { {
      classroomController,
      selectSubjectInput,
    } = ; subjectChosen = selectSubjectInput.value;
    classroomController.addClassroom(subjectChosen); .updateView();
  }

  removeClassroom(classroomID) { { classroomController } = ;
    classroomController.removeClassroom(classroomID); .updateView();
  }

  addPerson(person, classroomID) { { classroomController } = ;
    classroomController.addPerson(person, classroomID); .updateView();
  }
} import from "../controllers/classroom" import from "../models/subjects" class ClassroomView constructor this new this document 'div' this document 'div' this document 'button' this document 'select' this 'classroom-section' this 'classroom-container' this ( ) => option, index `<option key= value= > </option>` ${index} ${option} ${option.toUpperCase()} this 'New Class' this 'click' this this this this this this const this const => c const document 'button' const document 'div' 'classroom' if 'selected' 'click' this 'data-classroom-id' 'data-classroom-id' 'click' this 'data-classroom-id' 'data-classroom-id' 'remove-btn' 'remove' const => p `<div class="person-inline">
            <span class="fname"> </span>
            <span class="lname"> </span>
            <span class=" "> </span>
          </div>` ${p.firstName} ${p.lastName} ${p.occupation} ${p.occupation} `<div class="m-b">
            <span class="id"> </span>
            <span class="subject"> </span></div>
            <div class="all-persons"> </div>` ${c.id} ${c.subject} ${allPersons.join( )} '' return '' => div const this this const this const this const this this const this this The class contains a variable that links to a which is created upon construction. This allows communication with the controller from the view. ClassroomView ClassroomController The function is ran after every change as a result from user Interactions. This function simply updates all related view elements with the appropriate data obtained from the associated model. updateView() DOM All functions within the view simply grab values from the ( elements and transfer them as variables to the controller's functions. The functions , and are all added to the elements via the function as events through the function. User Interface UI) DOM selectClassroom() addClassroom() removeClassroom() DOM updateView() addEventListener() Accessing all controllers and views through a single view Now, since for this example we have two controllers, a and a ( ). We would also have two views and if we wanted these two views to be able to interact with one another we would create a single overarching view. We could call this view the . Classroom Controller Person Controller Shown in full project Application View classroomView ; personView ; { (appDiv) { .classroomView = classroomView(appDiv); .personView = personView(appDiv); .addPersonToClassBtn = .createElement( ); .addPersonToClassBtn.textContent = ; .addPersonToClassBtn.addEventListener( , () => .addPersonToClass());
    appDiv.appendChild( .addPersonToClassBtn);
  }

  addPersonToClass() { { classroomView, personView } = ; { classroomController } = classroomView; { personController } = personView; selectedClassroom = classroomController.selectedClass; selectedPerson = personController.selectedPerson;
    classroomView.addPerson(selectedPerson, selectedClassroom);
    personView.updateView();
  }
} import from './classroom' import from './person' class AppView constructor this new this new this document 'button' this 'Add selected Person to Selected Class' this 'click' this this const this const const const const This class would have it's own variables that would link to both the and views. Since it has access to those two views it also has access to their controllers. ApplicationView classroom person This button above is generated by the view. It grabs the and values from their respective controllers and runs the function in the classroom view upon interaction. Application selectedClassroom selectedPerson addPerson() For a full look at the Classroom App check out the CodeSandBox Here! Some Advantages of Using the MVC Framework Sources: , , , Brainvire c-sharpcorner StackOverflow Wikipedia 1. Separation of Concerns All code related to the is handled by the . All base data variables are contained by the and all model data is changed through the . User Interface view Model Controller 2. Simultaneous Development Since this model clearly separates the project into three (3) layers it becomes a lot easier to separate and assign tasks to multiple developers. MVC 3. Ease of Modification Can easily make changes to each layer without immediately affecting the other layers. 4. Test Driven Development (TDD) With clear separation of concerns it allows the testing of each individual component independently.

How I Adopted the Model, View, Controller (MVC) Architectural Pattern in JavaScript

Courtesy The first step in optimizing a query is looking at it’s execution plan. An execution plan is a visual representation of the operations performed by the engine in order to return the data required by your query. database The execution plan for a query is your view into the Server query optimizer and query engine. It will reveal which , object like: SQL objects a query uses tables indexes etc. type of uses: in which order how they were accessed (seek or scan) types of joins data size filtering sorting aggregations calculated columns derivation foreign keys access etc. within the database, and how it uses them. There are 3 types of execution plans: Estimated Actual Cached Estimated execution plan: To get a query’s estimated execution plan: Switch to the database in concern highlight the query in concern click Query click Display Estimated Execution Plan The shortcut for this is Ctrl+ L. When you get this plan, some sections of the query might show a very high percentage as cost. Remember that this is just an estimate, and many a times what we see as the most expensive section comes up as the most cheapest or cheap. Btw, each symbol in the execution plan is an operator, and each operator has additional information within its properties that define the work performed by that operator. Actual execution plan: To get a query’s actual execution plan: Switch to the database in concern highlight the query in concern click Query click Include Actual Execution Plan The shortcut for this is Ctrl+ M. One of the queries gave this actual execution plan. Look at the actual vs estimated numbers, looks like the estimate is good enough. One of other queries gave this execution plan: Looks like the estimates and actuals are far different. This proves that . Btw, we read execution plans from left to right and top to bottom. actual execution plan are always good to tune compared to estimates The estimated percentage costs at the front level are . So to tune the queries, it looks like we need to go through each of the blocks one-by-one. This looks like a lot of pain. This is where the 3rd type of execution plans comes into the picture — the . still estimates cached execution plan Cached execution plan: There is a to find out which queries we actually need to tune. Just hit and grab . free cool utility http://www.brentozar.com/blitzcache sp_BlitzCache Just execute this . This query will give the top 10 queries with the most execution time. In a column it also shows the possible problems like missing indexes, downlevel cardinality estimates and implicit conversions in the column. In the column, it gives the actual execution plan map link which can be clicked upon. EXEC sp_BlitzCache @top=10, @sort_order='duration' Warnings Query Plan Query Tuning: The single largest use for execution plans is query tuning. It’s the most common tool for understanding what you want to tune. It’s invaluable for identifying and fixing poorly performing code. I can’t run through every potential cause of poor query performance here, or even close, but we can look briefly at a few of the common culprits and the warning signs you’ll find in the execution plan. Poorly Designed Queries Like with any language, there are common code smells within T-SQL. I’ll list out a few of them as well as what you might see in the execution plan. Search Conditions with Functions Placing a function on a column in the , or clause (e.g. can lead to very poor performance because it renders the predicate non-SARGable, which means that SQL Server cannot use it in an index seek operation. Instead, it will be forced to read the entire table or index. In the execution plan, look out for a Scan operator against a table or index where you expected a Seek operation, i.e. a single or small set of lookups within an index. ON HAVING WHERE WHERE SomeFunction(Column) = @Value ) Nesting Views Having a view that calls to other views or has operations to other views can lead to very poor performance. The query optimizer goes through a process called simplification, where it attempts to eliminate tables that are not needed to fulfil the query, helping to make it faster. For simple queries involving views or functions, the optimizer will simply access the underlying base tables, and perform table elimination in the usual fashion. However, use of nested views and functions will lead quickly to a very complex query within SQL Server, even if the query looks simple in the T-SQL code. The problem is that beyond a certain point, SQL Server can’t perform the usual simplification process, and you’ll end up with large complex plans with lots of operators referencing the tables more than once, and so causing unnecessary work. JOIN Incorrect Data Type Use Of course, to do this it must apply the conversion function to the column, in the , or clause and we are back in the situation of having a non-SARGable predicate, leading to scans where you should see seeks. You may also see a warning indicating an implicit conversion is occurring. ON HAVING WHERE Row-by-row Processing Row-by-row approach is expressed via cursors and sometimes as loops that often lead to extremely poor performance. In such cases, rather than a single execution plan, you’ll see one plan for each pass through of the loop, and SQL Server essentially generates the same plan over and over, to process each row. WHILE Common Warning Signs in the Execution Plan Warnings These are red crosses or yellow exclamation marks superimposed on an operator. There are sometimes false positives, but most of the time, these indicate an issue to investigate. Costly Operations — the operation costs are estimated values, not actual measures, but they are the one number provided to us so we’re going to use them. The most costly operation is frequently an indication of where to start troubleshooting Fat Pipes Within an execution plan, the arrows connecting one operator to the next are called pipes, and represent data flow. Fat pipes indicate lots of data being processed. Of course, this is inevitable if the query simply has to process a large amount of data, but it can often be an indication of a problem. Look out for transitions from very fat pipes to very thin ones, indicating late filtering and that possibly a different index is needed. Transitions from very thin pipes to fat ones indicates multiplication of data, i.e. some operation within the T-SQL is causing more and more data to be generated. Extra Operators Over time you’ll start to recognize operators and understand quickly both what each one is doing and why. Any time that you see an operator and you don’t understand what it is, or, you don’t understand why it’s there, then that’s an indicator of a potential problem. Scans We say this all the time, scans are not necessarily a bad thing. They’re just an indication of the scan of an index or table. If your query is , with no clause then a scan is the best way to retrieve that data. In other circumstances, a scan can be an indication of a problem such as implicit data conversions, or functions on a column in the clause. SELECT * FROM TableName WHERE WHERE Let’s take a look at a few of the warning signs that can appear, and what we can do in response. DECLARE @LocationName AS NVARCHAR(50); SET @LocationName = 'Paint'; SELECT  p.Name AS ProductName ,        pi.Shelf ,        l.Name AS LocationNameFROM    Production.Product AS p        JOIN Production.ProductInventory AS pi ON pi.ProductID = p.ProductID        JOIN Production.Location AS l ON l.LocationID = pi.LocationIDWHERE   LTRIM(RTRIM(l.Name)) = @LocationName;GO And the problems are as follows: The INDEX SCAN on the column – there’s an index on that column a SEEK is expected - culrit: , in the clause Location.Name LTRIM(RTRIM(l.Name)) WHERE The FAT PIPE coming out of the Clustered Index Scan on the ProductInventory table — in this example, it’s processing over 1000 rows at this stage, and eventually only returning 9 rows. — culprit: missing index on the column. The HASH MATCH join — for the number of rows returned I’m expecting a NESTED LOOPS join — culprit: bad or missing indexes. Poor Indexing At the top of some execution plans, you may even see an explicit suggestion, indicating that the optimizer recognized that if it had a certain index, it might be able to come up with a better plan. Note these, but do not assume they’re accurate. Test them before applying them. Missing Index Nesting Views A view is just a query that the optimizer resolves just like any other query. However, if you decide to JOIN a view to a view, or nest views inside of each other, it causes problems for SQL Server. Firstly, as the number of referenced objects increases, due to deep nesting, the optimizer, which only has so much time to try to optimize the query, will give up on simplification and just build a query for the objects defined. For each object, the optimizer must estimate the number of rows returned and, based on that, the most efficient operation to use to return those rows. However, once we go beyond levels deep on obfuscation, the optimizer stops assigning costs and just assumes one row returned. All of this can result in very poor choices of plan and a lot of avoidable work. three To illustrate how nesting views can hurt the server, consider this: SELECT  pa.PersonName,        pa.City,        cea.EmailAddress,        cs.DueDateFROM    dbo.PersonAddress AS paJOIN    dbo.CustomerSales AS cs        ON cs.CustomerPersonID = pa.PersonIDLEFT JOIN dbo.ContactEmailAddress AS cea        ON cea.ContactPersonID = pa.PersonIDWHERE   pa.City = 'Redmond'; All the 3 referenced objects are views. And the execution plan will be so complex like this: The simplication of the above query can be done by actually accessing the underlying tables like this: SELECT  p.LastName + ', ' + p.FirstName AS PersonName ,        a.City ,        ea.EmailAddress ,        soh.DueDateFROM    Person.Person AS p        JOIN Person.EmailAddress AS ea              ON ea.BusinessEntityID = p.BusinessEntityID        JOIN Person.BusinessEntityAddress AS bea              ON bea.BusinessEntityID = p.BusinessEntityID        JOIN Person.Address AS a              ON a.AddressID = bea.AddressID        LEFT JOIN Person.BusinessEntityContact AS bec              ON bec.PersonID = p.BusinessEntityID        JOIN Sales.Customer AS c              ON c.PersonID = p.BusinessEntityID        JOIN Sales.SalesOrderHeader AS soh              ON soh.CustomerID = c.CustomerIDWHERE   a.City = 'Redmond'; The execution plan is much simplified now: Lack of Database Constraints Consider this query: SELECT  soh.OrderDate ,        soh.ShipDate ,        sod.OrderQty ,        sod.UnitPrice ,        p.Name AS ProductNameFROM    Sales.SalesOrderHeader AS soh        JOIN Sales.SalesOrderDetail AS sod              ON sod.SalesOrderID = soh.SalesOrderID        JOIN Production.Product AS p               ON p.ProductID = sod.ProductIDWHERE   p.Name = 'Water Bottle - 30 oz.'        AND sod.UnitPrice < $0.0; With no constraints in place, the execution plan for this query will look as shown: This query returns zero rows, since there are no products with a price less than $0, and yet SQL Server still performs an index scan, two index seeks and a couple of nested loop joins. The reason is that it has no way to know they query will return zero rows. However, what if we have a constraint in place on the SalesOrderDetail table that requires that the UnitPrice for any row be greater than zero (this constraint already exists in the AdventureWorks database). ALTER TABLE Sales.SalesOrderDetail  WITH CHECK  ADD  CONSTRAINT CK_SalesOrderDetail_UnitPrice CHECK  ((UnitPrice>=(0.00))); If we rerun the above code with this constraint in place, then the execution plan is interesting: Missing or out-of-date Database Statistics The statistics can be turned off or on by the following command: SET AUTO_UPDATE_STATISTICS OFF | ON; It is recommended to not set them off to avoid stale statistics. Maybe it’s not the Database? It’s also possible that the database is not the culprit, the application can cause performance problems. So, profile the application code as well. Sources: Execution plan benefits Types of execution plans Photos

Execution plan in SQL Server

In this part of the article we’re going to write our own library using . If you haven’t read yet, it’s strongly advised. It covers the basics of starting a new and an existing project with compiler. Elmchemy part one integrating Elmchemy During this tutorial we’ll learn how to: Define type aliases Define union types Use aliases and tagged unions as functions Pattern match on union types Use operators as functions and define your own custom ones Import types and type aliases from other modules So imagine we’re writing a game. An amazingly innovative game. A game no-one has ever made before. With characters, levels, stats, and items kind of game. It is set in sci-fi-ish word so we can have crossbows, rifles, crowbars, blasters and what-not. Because we’re creating a block-buster and project managers rarely happen to have inconceivable deadline expectations, we were assigned a single task: our job is to create a module responsible for our main character — .We’re a start-up and our salary is roughly 5 hundred bucks a month, so we were given the opportunity to plan out the features ourselves (Product manager would say it’s not what he wanted anyway). Gordon Freemonad We’re one lazy programmer and we’ll use a project created in . If you don’t have it, then you already failed. There goes your equity. As a first step we’ll create several scenarios testing unimplemented features, and then we’ll start thinking on how to implement them (look it up. It’s called TDD and it’s closest to gaming at work you can get without getting fired). Testing suite will be implemented in Elixir’s ExUnit exactly like in the previous part of the tutorial, everything else will be coded using Elmchemy only. part one Enough talking. Time to start coding. Preparation *This article was written using Elmchemy 0.3.31. Make sure to have a version that is above 0.3.31 but no higher than 0.4* Due to your wage and non-negotiable full-time amount of hours a week, you suffer from World Of Warcraft withdrawal. A lack of your both most hated and beloved game results in a pretty bold statement: . Every game character has to have stats Let’s write a test that will check that new character has them.If you followed previous part your project structure should look like this: Create a new file called inside directory and start with a boilerplate: character_test.exs test test/character_test.exs - Ignore the error on `use Elmchemy`. Our plugin just can’t see dependencies that are installed as mix archives Now what our character should have? Definitely a name and a surname. Having some gender would be nice too. Age is overrated so let’s leave that out. Not much but might be enough for our MVP. test/character_test.exs Cool. Next thing is we want him to have basic stats. Strength for damage, intelligence for weapon requirements and vitality for health should be enough for our MVP. We don’t yet know what will be the default values so let’s just check if the stats exists and are integers. character_test.exs We also check if we are able to set a stat for our character, using function. set_stat/3 Stats would be nothing if they didn’t provide some benefit for having them: Vitality boosts our health presented as {current_hp, max_hp} tuple: test/character_test.exs — We check that max hp increased, and also that our current hp adjusted itself accordingly In our test we create a new Gordon and clone two copies of him. One beefed up with 10 vitality, and the other who’s a programmer like us - with 0. Then we compare their health points and expect the former to have more of them.In the last line we make sure that boosting Gordon’s max health, also raises his base health accordingly. *Please note that we put the target of our function as last parameter, rather then the first one. That’s because in curried environment for pipes to work, we need the have the piping target as last argument — and that’s Elm’s and Elmchemy’s standard* Intelligence allows us to equip more advanced weapons: test/character_test.exs — We create two Gordons, a weapon with 9 intelligence requirement, Here we create a new character and a weapon with level 9 and 100 damage.Then we get two clones of Gordon: - one with Intelligence - and the other one with .We ran function on both of them, and expect it to fail on the character with intelligence, but succeed on one with 10 0 equip 0 10 At the end we make sure that the smarter clone of Gordon has a weapon in his arm. Please notice that we wrap it in single tuple , because that’s how Elmchemy represents type. With being and being {weapon} [Maybe](http://package.elm-lang.org/packages/elm-lang/core/latest/Maybe) {value} Just value nil Nothing. Implementation Test #1 — Character name, surname and gender Feature 1— Type aliases Now that we have our tests we can start implementing our character!For our schema we’re going to use a . It allows us to have a common name for any other type. We’re going to use it to alias a struct. Which Elmchemy represents as a map with atoms as keys. type alias Create a file with our type alias declaration. elm/Character.elm elm/Character.elm : If the type we’re aliasing is a struct or a tuple, we can use the alias as a function to create an instance of it with each argument being a each subsequent value in our type. f.i Type Alias Tip Character name surname gender health We declare our Character to have a name and a surname, which are strings.A gender of type which is a type we didn’t declare yet, and health as tuple, where the first one is current health, and the latter is max health. Gender Feature 2— Union Types Whenever we wan’t something to be matched on, we want a custom type.In Elmchemy are so called which basically means, the first symbol in each type declaration is a ‘tag’ that tells us what type the value represents. Union types in Elmchemy are represented as atoms in case of a single tag, and a tuple starting with an atom in case of tags wrapping one or more type.That’s how we’re going to declare our gender types ‘Tagged unions’ elm/Character.elm — We declare that gender can either be an atom :male, :female or :other Feature 3— Type Aliases as functions Now we can declare a function that returns a new character based on it’s parameters. new elm/Character.elm — function returning our Character type alias intance We take 3 parameters, which are name and surname as strings and a gender as our newly created union type. Then we pass the arguments to Character type as a function in the order we defined the fields.We also pass the default argument of health being 100 on 100 max. Gender If we run in our terminal right now we should have our first test passing. 3 to go! mix test Test #2 — Character stats Time to add stats. Let’s recall our test case character_test.exs First we need to define stats for our character type. And also define the stats structure: When we save, our compiler should nag us, that our function is no longer relevant to our type. new/3 Lets update it to contain default stats all being of value 0 Feature 4 — case statement on union types and record update syntax We need a type of a stat to match on Now we need to declare a function that takes a stat, value and character, and updates the stat to the value we want. **Did you know?**You can define type aliases using record update syntax. means any structure that has a field of type .You can then create types deriving from it like so: But remember, that way you sacrifice the short syntax for instantiating type aliases and have to type the entire struct by hand. type alias Namable a = { a | name : String} name String type alias Cat = Namable { lactoseIntolerance : Bool }   ``type alias Dog = Namable { catIntolerance : Int } Great. That’s another test down! Test #3 — Boosting vitality test/character_test.exs — We check that max hp increased, and also that our current hp adjusted itself accordingly Now we need to add the functionality of changing health when setting a vitality stat. Feature 5— Operators as functions and custom operators Because our HP is a tuple we want to use on it. But for the sake of code tidiness we’re going to define an operator for us to use that as infix operator. Tuple.map We could use any operator i like, but for the sake of the shape I chose for the left tuple element and for the right one. You can experiment with what works best for you. <$ $> There is plenty of built in operators to make your life easier. You can use and to pipe function results, and to compose functions. There even is a comma operator that creates tuples for you. is equivalent to to and so on.Every operator is still a function so we can pass them to other functions to make our code much more expressive.All it takes to implement a zip of two lists is just to write Did you know? |> <| << >> (,) a b (a, b)   (,,) a b c (a, b, c) List.map2 (,) listA listB Great. Now we can add the health change to the branch of our case. Vitality setStat We use to add a difference of current vitality and a new vitality value multiplied by 10.Then we use to set it to base 100 plus 10 times the vitality value.Since we need to pass it a function in the first case we give it a function and in the second we give it which basically returns the same thing (Basically it means the same as )If we didn’t use our operator the code would look as follows <$ $> (+) always always \_ -> (100 + 10 * value) character.health|> Tuple.mapFirst ((+) ((value - character.stats.vitality) * 10))|> Tuple.mapSecond (always (100 + 10 * value)) By now we should be with only one test failing left. Test #4 — Equipping a weapon when we’re intelligent enough test/character_test.exs - a weapon with 9 intelligence requirement, So we need a function, that either can or cannot equip a weapon. To do that we’re going to use type, that have a value of either or , which directly translates to or . Result a b Err a Ok b {:ok, a} {:error, b} Please notice the difference of Err translating to instead of . That’s one of exceptions in Elmchemy to keep Elixir and Elm interoperable without a consistency sacrifice :error :err But before we do that, we need to implement a Weapon type in general. To do that we’re create a new file, and learn to import and use remote types. Feature 6 — Union types and Type Aliases imported from other modules Let’s create a new file and add a function that would create a weapon for us elm/Weapon.elm new elm/Weapon.elm — weapon type definition *Please note that we create a _new_ function only for the sake of usage inside our Elixir code. The _Weapon_ type alias is a factory function itself when used inside Elmchemy’s scope. _Character_ factory function ( _Character.new_ ) was different because we specified some default values for it* Now that we have our type we can implement our function, but first we need to add an import on the top of our file, we use because the first one is the name of the module, and the latter of the type alias we want to import. Weapon equip Character.elm import Weapon exposing (Weapon) Also our character is right now armless. Let’s add it an arm, of type . Like we decided earlier we want to use type, because our character can either have something in his hand or have nothing at all.Let’s add an arm to our type with Maybe Weapon Maybe Character **Did you know?**There is a shorthand syntax to access a field in a struct as a function.By writing you can have a function that will fetch of a record. It’s equivalent to For example: .field field \a -> a.field arsenal : List Character -> List Weapon arsenal squad = List.map .arm _squad_ We need to add a default value for to our function too. arm Character.new elm/Character.elm Now that we have the type imported from the other file and an arm for our character we can go about our weapon equipping implementation: elm/Character.elm That’s it! If we run the tests now, we should see all 4 tests green. If you skipped some parts you can see the entire project under this repository: https://github.com/wende/elmchemy-article-example This is the end of part twoIn part three we will focus on calling Elixir code from Elmchemy and writing your own Native modules. In case of any questions regarding the project I’ll gladly answer in the comments section. Announcement: Elmchemy is undergoing a name change and is soon to be called “Elchemy” (without an “m”) <<< — Part One — Part Three >>>

Stories, News & Mentions about UPPFIRST

Uppfirst’s Stories on HackerNoon