/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    img: "img",
    h2: "h2",
    ol: "ol",
    li: "li"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Every system has its limits. When designing and architecting systems, sometimes we as engineers like to assume things can scale infinitely. Maybe we can use larger machines, or maybe we can deploy more instances of a service. But even trying to scale systems isn’t magically infinite. It’s a smart move to understand the limitations of what we are building upfront so we can make better technology choices, and squeeze the performance out of our existing systems."
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.img, {
        src: "/media/2023-12-08-the-breaking-point/splash.png",
        alt: "The Breaking Point"
      })
    }), "\n", _jsx(_components.h2, {
      children: "The Myth of Scaling"
    }), "\n", _jsx(_components.p, {
      children: "Software engineering often has an optimistic mindset that scaling a service is easy: we just let the more instances of the service be deployed, and viola, perfect scaling! But the reality is a bit more complex. Instances don't always fire up instantly, services can fail unexpectedly, and not every component can scale indefinitely."
    }), "\n", _jsx(_components.p, {
      children: "That’s why it’s important to understand the limitations of our services. Knowing where the system might buckle under pressure allows us to devise strategies to prevent these breaking points from turning into disasters."
    }), "\n", _jsx(_components.p, {
      children: "For example, we may have a public API service with set auto-scaling rules. When the service is hit with many requests, the service spawns additional instances to handle the workload. This ends up working well in most cases, but in the real-world, the service ends up getting hit with huge bursts of requests from downstream users, rather than a steady increase of traffic. When this happens, we scale the service instances up, but now the database gets hit with too many writes and fails over, since the database was originally designed as a read heavy use-case. Of course this is a contrived example, but similar edge-cases commonly appear in complex architectures."
    }), "\n", _jsx(_components.p, {
      children: "Without understanding the full system and the constraints of each part, it can be difficult to successfully scale."
    }), "\n", _jsx(_components.h2, {
      children: "Understanding Server Limitations"
    }), "\n", _jsx(_components.p, {
      children: "A good starting point for finding your system’s breaking point is to see how it fares on a single machine. Profile the memory usage when under load, and use load testing to determine how many simultaneous requests the service can handle before performance degrades. To make sense of it all, set some benchmarks:"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Determine what it means for performance to degrade. In some systems, you may have SLAs for some percentage of requests to complete within a given response time. Other systems may have more leniency."
      }), "\n", _jsx(_components.li, {
        children: "Use readily available tools to bombard your service with requests and observe the results. For web API services, there are plenty of open source tools that can sustain issuing millions of requests a second and reporting results."
      }), "\n", _jsx(_components.li, {
        children: "Run the tests multiple times and throw out any outliers in the results. From the rest, understand the peak memory usage, peak disk usage, and peak CPU usage of the service."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Once you have the information from these types of load tests, it becomes easy to identify indicators that a service will begin to degrade. For some services it is CPU usage that will increase more than the other resources. For some services, memory can get exhausted first."
    }), "\n", _jsx(_components.p, {
      children: "The load testing will also be a good indicator of how many requests a single instance of your service can handle before falling over."
    }), "\n", _jsx(_components.h2, {
      children: "Scaling Strategies"
    }), "\n", _jsx(_components.p, {
      children: "When dealing with monolithic services or hefty microservices, you may find from load testing that just vertically scaling the service by adding more hardware is more cost efficient than replicating the instance."
    }), "\n", _jsx(_components.p, {
      children: "Fore smaller service that use less memory and CPU footprint, it may make more sense to horizontally scale the service with many additional smaller servers being deployed."
    }), "\n", _jsx(_components.p, {
      children: "Cloud services like AWS, Azure, and GCP help enable either decision. With AWS, there are many different instance types to get the right size for your specific service deployment. With the right size picked out, auto-scaling becomes a more budget-friendly option, as you're only spinning up instances that meet your specific resource requirements."
    }), "\n", _jsx(_components.p, {
      children: "Cloud providers additionally have ways to detect when to auto-scale an instance based on resource usage, making load testing very informative to tune these values."
    }), "\n", _jsx(_components.h2, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "Scaling isn’t a one-size-fits-all solution. It’s about understanding the unique limitations and potential of your system. Through careful analysis, load testing, and a bit of strategic thinking, you can develop a scaling strategy that not only meets your performance needs but also keeps an eye on the cost of your system. Whether it’s beefing up your hardware or multiplying smaller instances, the key lies in making informed, tailored decisions for your system's specific demands and quirks."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Every system has its limits. When designing and architecting systems, sometimes we as engineers like to assume things can scale infinitely. Maybe we can use larger machines, or maybe we can deploy more instances of a service. But even trying to scale systems isn’t magically infinite. It’s a smart move to understand the limitations of what we are building upfront so we can make better technology choices, and squeeze the performance out of our existing systems.</p>
<p><img alt="The Breaking Point" src="/media/2023-12-08-the-breaking-point/splash.png" style="max-height:500px;margin:auto;text-align:center"/></p>
<h2>The Myth of Scaling</h2>
<p>Software engineering often has an optimistic mindset that scaling a service is easy: we just let the more instances of the service be deployed, and viola, perfect scaling! But the reality is a bit more complex. Instances don&#x27;t always fire up instantly, services can fail unexpectedly, and not every component can scale indefinitely.</p>
<p>That’s why it’s important to understand the limitations of our services. Knowing where the system might buckle under pressure allows us to devise strategies to prevent these breaking points from turning into disasters.</p>
<p>For example, we may have a public API service with set auto-scaling rules. When the service is hit with many requests, the service spawns additional instances to handle the workload. This ends up working well in most cases, but in the real-world, the service ends up getting hit with huge bursts of requests from downstream users, rather than a steady increase of traffic. When this happens, we scale the service instances up, but now the database gets hit with too many writes and fails over, since the database was originally designed as a read heavy use-case. Of course this is a contrived example, but similar edge-cases commonly appear in complex architectures.</p>
<p>Without understanding the full system and the constraints of each part, it can be difficult to successfully scale.</p>
<h2>Understanding Server Limitations</h2>
<p>A good starting point for finding your system’s breaking point is to see how it fares on a single machine. Profile the memory usage when under load, and use load testing to determine how many simultaneous requests the service can handle before performance degrades. To make sense of it all, set some benchmarks:</p>
<ol>
<li>Determine what it means for performance to degrade. In some systems, you may have SLAs for some percentage of requests to complete within a given response time. Other systems may have more leniency.</li>
<li>Use readily available tools to bombard your service with requests and observe the results. For web API services, there are plenty of open source tools that can sustain issuing millions of requests a second and reporting results.</li>
<li>Run the tests multiple times and throw out any outliers in the results. From the rest, understand the peak memory usage, peak disk usage, and peak CPU usage of the service.</li>
</ol>
<p>Once you have the information from these types of load tests, it becomes easy to identify indicators that a service will begin to degrade. For some services it is CPU usage that will increase more than the other resources. For some services, memory can get exhausted first.</p>
<p>The load testing will also be a good indicator of how many requests a single instance of your service can handle before falling over.</p>
<h2>Scaling Strategies</h2>
<p>When dealing with monolithic services or hefty microservices, you may find from load testing that just vertically scaling the service by adding more hardware is more cost efficient than replicating the instance.</p>
<p>Fore smaller service that use less memory and CPU footprint, it may make more sense to horizontally scale the service with many additional smaller servers being deployed.</p>
<p>Cloud services like AWS, Azure, and GCP help enable either decision. With AWS, there are many different instance types to get the right size for your specific service deployment. With the right size picked out, auto-scaling becomes a more budget-friendly option, as you&#x27;re only spinning up instances that meet your specific resource requirements.</p>
<p>Cloud providers additionally have ways to detect when to auto-scale an instance based on resource usage, making load testing very informative to tune these values.</p>
<h2>Conclusion</h2>
<p>Scaling isn’t a one-size-fits-all solution. It’s about understanding the unique limitations and potential of your system. Through careful analysis, load testing, and a bit of strategic thinking, you can develop a scaling strategy that not only meets your performance needs but also keeps an eye on the cost of your system. Whether it’s beefing up your hardware or multiplying smaller instances, the key lies in making informed, tailored decisions for your system&#x27;s specific demands and quirks.</p>


Every system has its limits. When designing and architecting systems, sometimes we as engineers like to assume things can scale infinitely. Maybe we can use larger machines, or maybe we can deploy more instances of a service. But even trying to scale systems isn’t magically infinite. It’s a smart move to understand the limitations of what we are building upfront so we can make better technology choices, and squeeze the performance out of our existing systems.

![The Breaking Point](/media/2023-12-08-the-breaking-point/splash.png)

## The Myth of Scaling

Software engineering often has an optimistic mindset that scaling a service is easy: we just let the more instances of the service be deployed, and viola, perfect scaling! But the reality is a bit more complex. Instances don't always fire up instantly, services can fail unexpectedly, and not every component can scale indefinitely.

That’s why it’s important to understand the limitations of our services. Knowing where the system might buckle under pressure allows us to devise strategies to prevent these breaking points from turning into disasters.

For example, we may have a public API service with set auto-scaling rules. When the service is hit with many requests, the service spawns additional instances to handle the workload. This ends up working well in most cases, but in the real-world, the service ends up getting hit with huge bursts of requests from downstream users, rather than a steady increase of traffic. When this happens, we scale the service instances up, but now the database gets hit with too many writes and fails over, since the database was originally designed as a read heavy use-case. Of course this is a contrived example, but similar edge-cases commonly appear in complex architectures.

Without understanding the full system and the constraints of each part, it can be difficult to successfully scale.

## Understanding Server Limitations

A good starting point for finding your system’s breaking point is to see how it fares on a single machine. Profile the memory usage when under load, and use load testing to determine how many simultaneous requests the service can handle before performance degrades. To make sense of it all, set some benchmarks:

1. Determine what it means for performance to degrade. In some systems, you may have SLAs for some percentage of requests to complete within a given response time. Other systems may have more leniency.
2. Use readily available tools to bombard your service with requests and observe the results. For web API services, there are plenty of open source tools that can sustain issuing millions of requests a second and reporting results.
3. Run the tests multiple times and throw out any outliers in the results. From the rest, understand the peak memory usage, peak disk usage, and peak CPU usage of the service.

Once you have the information from these types of load tests, it becomes easy to identify indicators that a service will begin to degrade. For some services it is CPU usage that will increase more than the other resources. For some services, memory can get exhausted first.

The load testing will also be a good indicator of how many requests a single instance of your service can handle before falling over.

## Scaling Strategies

When dealing with monolithic services or hefty microservices, you may find from load testing that just vertically scaling the service by adding more hardware is more cost efficient than replicating the instance.

Fore smaller service that use less memory and CPU footprint, it may make more sense to horizontally scale the service with many additional smaller servers being deployed.

Cloud services like AWS, Azure, and GCP help enable either decision. With AWS, there are many different instance types to get the right size for your specific service deployment. With the right size picked out, auto-scaling becomes a more budget-friendly option, as you're only spinning up instances that meet your specific resource requirements.

Cloud providers additionally have ways to detect when to auto-scale an instance based on resource usage, making load testing very informative to tune these values.

## Conclusion

Scaling isn’t a one-size-fits-all solution. It’s about understanding the unique limitations and potential of your system. Through careful analysis, load testing, and a bit of strategic thinking, you can develop a scaling strategy that not only meets your performance needs but also keeps an eye on the cost of your system. Whether it’s beefing up your hardware or multiplying smaller instances, the key lies in making informed, tailored decisions for your system's specific demands and quirks.


The Breaking Point - Understanding the performance of your systems

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    a: "a",
    h2: "h2"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it."
    }), "\n", _jsx(_components.p, {
      children: "I’ve been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions."
    }), "\n", _jsxs(_components.p, {
      children: ["We ended up open sourcing as much of our Clarity Hub code as we could: ", _jsx(_components.a, {
        href: "https://github.com/Clarityhub",
        children: "Clarity Hub on Github"
      }), ". This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: ", _jsx(_components.a, {
        href: "https://github.com/clarityhub/clarityhub-server-core",
        children: "Architecture notes on Github"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem."
    }), "\n", _jsx(_components.p, {
      children: "The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration."
    }), "\n", _jsx(_components.p, {
      children: "The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn’t provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well positioned apps like Notion will be able to continue to get better."
    }), "\n", _jsx(_components.p, {
      children: "But not is all lost, part of failing as a start-up is at least learning a lot."
    }), "\n", _jsx(_components.h2, {
      children: "Microservices, but not really"
    }), "\n", _jsx(_components.p, {
      children: "Looking back on our startup adventure, one thing I’d recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly."
    }), "\n", _jsx(_components.h2, {
      children: "Billing"
    }), "\n", _jsx(_components.p, {
      children: "Billing is one of those items that can easily become a time-sync – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I’d ignore billing for just Free Trial and Contact Sales for custom billing."
    }), "\n", _jsx(_components.p, {
      children: "Without customers, there’s no point in building a billing system, especially when you don’t know what type of customers you will have."
    }), "\n", _jsx(_components.p, {
      children: "We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more."
    }), "\n", _jsx(_components.p, {
      children: "We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution."
    }), "\n", _jsx(_components.h2, {
      children: "Conflict-free replicated data types"
    }), "\n", _jsx(_components.p, {
      children: "We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage."
    }), "\n", _jsx(_components.p, {
      children: "Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used."
    }), "\n", _jsx(_components.h2, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I’ve often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it.</p>
<p>I’ve been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions.</p>
<p>We ended up open sourcing as much of our Clarity Hub code as we could: <a href="https://github.com/Clarityhub">Clarity Hub on Github</a>. This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: <a href="https://github.com/clarityhub/clarityhub-server-core">Architecture notes on Github</a>.</p>
<p>Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem.</p>
<p>The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration.</p>
<p>The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn’t provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well positioned apps like Notion will be able to continue to get better.</p>
<p>But not is all lost, part of failing as a start-up is at least learning a lot.</p>
<h2>Microservices, but not really</h2>
<p>Looking back on our startup adventure, one thing I’d recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly.</p>
<h2>Billing</h2>
<p>Billing is one of those items that can easily become a time-sync – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I’d ignore billing for just Free Trial and Contact Sales for custom billing.</p>
<p>Without customers, there’s no point in building a billing system, especially when you don’t know what type of customers you will have.</p>
<p>We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more.</p>
<p>We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution.</p>
<h2>Conflict-free replicated data types</h2>
<p>We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage.</p>
<p>Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used.</p>
<h2>Conclusion</h2>
<p>If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I’ve often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically.</p>


In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it.

I’ve been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions.

We ended up open sourcing as much of our Clarity Hub code as we could: [Clarity Hub on Github](https://github.com/Clarityhub). This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: [Architecture notes on Github](https://github.com/clarityhub/clarityhub-server-core).

Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem.

The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration.

The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn’t provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well positioned apps like Notion will be able to continue to get better.

But not is all lost, part of failing as a start-up is at least learning a lot.

## Microservices, but not really

Looking back on our startup adventure, one thing I’d recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly.

## Billing

Billing is one of those items that can easily become a time-sync – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I’d ignore billing for just Free Trial and Contact Sales for custom billing.

Without customers, there’s no point in building a billing system, especially when you don’t know what type of customers you will have.

We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more.

We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution.

## Conflict-free replicated data types

We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage.

Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used.

## Conclusion

If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I’ve often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically.


Looking back on Clarity Hub

/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, props.components);
  return _jsx(_components.p, {
    children: "Dive into the dynamic world of the WAX blockchain with this comprehensive tutorial series. From creating unique non-fungible tokens (NFTs) using AtomicAssets and crafting simple \"Hello World\" contracts, to deploying intricate guestbook contracts both locally and on the testnet, these tutorials provide a step-by-step guide to harnessing the full potential of WAX. Whether you're a developer eager to explore decentralized applications or an enthusiast curious about digital assets, this series offers invaluable insights into the robust capabilities of the WAX platform."
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Dive into the dynamic world of the WAX blockchain with this comprehensive tutorial series. From creating unique non-fungible tokens (NFTs) using AtomicAssets and crafting simple &quot;Hello World&quot; contracts, to deploying intricate guestbook contracts both locally and on the testnet, these tutorials provide a step-by-step guide to harnessing the full potential of WAX. Whether you&#x27;re a developer eager to explore decentralized applications or an enthusiast curious about digital assets, this series offers invaluable insights into the robust capabilities of the WAX platform.</p>


Dive into the dynamic world of the WAX blockchain with this comprehensive tutorial series. From creating unique non-fungible tokens (NFTs) using AtomicAssets and crafting simple "Hello World" contracts, to deploying intricate guestbook contracts both locally and on the testnet, these tutorials provide a step-by-step guide to harnessing the full potential of WAX. Whether you're a developer eager to explore decentralized applications or an enthusiast curious about digital assets, this series offers invaluable insights into the robust capabilities of the WAX platform.

My e-book on WAX Smart Contract development that guides developers through the process of creating a non-fungible token (NFT) smart contract.


Interactive Smart Contracts on WAX

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "This is a 22 part series on DevTo that goes through the entire process of creating\na WAX Smart Contract that interacts with AtomicAssets and the WAX RNG Oracle."
    }), "\n", _jsx(_components.p, {
      children: "It is a great introduction to WAX smart contract development and the WAX ecosystem."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>This is a 22 part series on DevTo that goes through the entire process of creating
a WAX Smart Contract that interacts with AtomicAssets and the WAX RNG Oracle.</p>
<p>It is a great introduction to WAX smart contract development and the WAX ecosystem.</p>


This is a 22 part series on DevTo that goes through the entire process of creating
a WAX Smart Contract that interacts with AtomicAssets and the WAX RNG Oracle.

It is a great introduction to WAX smart contract development and the WAX ecosystem.


WAX smart contract development course that guides developers through the process of creating a non-fungible token (NFT) smart contract.


Welcome

Latest Posts

The Breaking Point - Understanding the performance of your systems

Looking back on Clarity Hub

Latest Projects

Interactive Smart Contracts on WAX

WAX C++ NFT Tutorial