DEV Community: Jungle Sven

Trading System Components

Jungle Sven — Sat, 27 Jul 2024 05:07:57 +0000

In the last article, I discussed best practices for developing trading software, such as using events, data storage, or separate configurations. This time, let's delve into the strategic part, specifically how to organize it effectively from an architectural standpoint.

Strategy Module

The simplest approach is to assume that this part of the system receives input data, such as price changes, and generates events—signals. All logic can be encapsulated within this module. Here’s an example:

def run(self, event):
    signal = self.calc_rsi(event)
    if signal != 'FLAT':
        self.create_event(event, signal)

In this example, we calculate the RSI and generate events like BUY or SELL based on it. This is a basic illustration, but the concept is clear. The signal might include the desired buy/sell price. Of course, a real trading algorithm is more complex, but you already know that!

Portfolio Module

It's beneficial to have all data on balances or open positions gathered in one place. This way, you know your total holdings in USD or BTC. This knowledge is essential for determining the size of your orders when the system generates signals.

def run(self, event):
    # Calculate USD values
    # Calculate targets
    # Check targets
    # Generate orders

This pseudocode outlines the following steps:

Calculate the total balances in USD
Determine portfolio targets according to the strategy
Check if current balances meet the targets
Generate orders of the necessary size if there are discrepancies

You get all the balance data, signals, verify if the positions align with the desired ones, and generate orders if they don't.

Risk Management Module

This module is closely related to the Portfolio module. Sometimes, risk management logic can be implemented directly within it, especially if you're managing a small sum and have just started. For large firms, this could be the most complex system element, and each firm defines its precise algorithm. Here are some tasks that can be addressed within risk management:

Check correlations between positions to avoid 100% long or short
Verify the maximum size of one position
Halt the entire system if losses reach a certain percentage
Stop the system in case of data stream failures or other components issues

The longer you’re in the market, the more critical this part of the trading algorithm becomes.

Execution Module

After obtaining all price and balance data, generating signals, calculating the optimal portfolio size, and accounting for all possible risks, there’s no reason not to send an order to the exchange. This might seem like the simplest part unless you're implementing order routing across multiple exchanges. Usually, you format the order correctly and send it to the exchange you trade on.

We discussed the functions of four modules, each of which is useful in 90% of trading algorithms. Structure your code, choose a good architecture, and maintaining and updating your trading system will be much less painful.

The complete code will be available as an open-source trading algorithm for aspis.finance. It will include a couple of simple trading strategies, but the key feature is the ability to create storage through Aspis smart contracts, attract investor funds, and ensure transparent profit-sharing. You can develop your strategy, connect it to Aspis, your algorithm will trade on DEXs, and investors and managers (you) will earn profit through a smart contract. Stay tuned!

Simple Yet Effective Architecture Patterns for Algorithmic Trading

Jungle Sven — Wed, 17 Jul 2024 15:59:42 +0000

In this thread, I'll show you how to develop trading software that is easy to maintain and update, while making it simple to collect statistics and track bugs.

1/ Events-Driven Architecture

At the core of this architecture are EVENTS. Every significant action, such as receiving data or processing results, will generate events. This approach allows:

Clear tracking of system activities
Standardized interaction between system components
Easy addition of new event handlers

Example of an event:

class BalanceUpdate(Event):
    def __init__(self, timestamp, symbol, amount) -> None:
        self.type = 'BALANCEUPDATE'
        self.timestamp = timestamp
        self.symbol = symbol
        self.amount = float(amount)

In our trading system, we need balance updates via websocket or REST API. Other updates include price changes, order info, and internal system events. Each module handles a specific function and generates events like BalanceUpdate.

2/ Data Storage

It's most efficient to store all data in a single repository. This includes price updates, balances, order data, signals, etc. Here's the workflow: The data module requests from a remote server, processes the response, and generates an event. Event handlers then save these data to the repository or trigger other handlers.

class Balances:
    def __init__(self):
        self.data = {}
        self.total = 0
        self.usd_values = {}

    def update(self, event):
        self.data[event.symbol] = event.amount

    def read(self):
        return self.data

Storing data in memory is the simplest and fastest method, suitable for most trading algorithms that don't require permanent data storage. For more complex needs, use Redis for an in-memory storage interface, especially when accessing data from other microservices.

3/ Configuration

Separating settings into a config file is good practice for trading software and any other system. This centralizes settings, making changes easy to manage.

Example config:

[general]
username = my_user_name

[trade]
markets = ['BTC/USDT', 'ETH/USDT']

Read config with configparser:

def read_config(self):
    config_object = ConfigParser()
    config_object.read('config.ini')
    settings = {sect: dict(config_object.items(sect)) for sect in config_object.sections()}
    settings['trade']['markets'] = eval(settings['trade']['markets']) #string to dict
    return settings

4/ Event Processing Loop

Consider this the main file coordinating all system elements:

Read settings from config
Initialize system modules with settings
Start the event processing loop
Launch tasks like balance updates every minute or continuous websocket listening

Example balance update event handling:

if event.type == 'BALANCEUPDATE':
    print('BALANCE UPDATE')
    self.data_storage.balances.update(event)
    self.data_storage.calc_usd_value()

In summary, we've covered several components of a trading system without delving into specific strategies: events, data storage, config, and event loop. These practices are essential for developing any trading algorithm. In the next article, I'll discuss strategy modules, portfolio management, risk management, and order execution.

All the code will be open-source and available upon the beta release of the service, developed in collaboration with aspis.finance —a DeFi platform that makes trader-investor relationships transparent through smart contracts.

Got questions? Reach out on TG @JungleSven.

Using Standard Deviation for Signals and Spreads

Jungle Sven — Thu, 14 Sep 2023 13:11:53 +0000

I'll show you how to use standard deviation to attempt to predict price reversals. As a bonus, we'll measure volatility ranges to place orders at optimal distances from the mean price.

Signals

We'll try to predict price reversals from peak values to the mean using standard deviation. The idea is that the market often returns to mean values after "overheating." These peak values correspond to peak standard deviation values.

Of course, this alone isn't enough to reliably predict price direction. So, we'll use two filters.

First, the standard deviation must decrease to avoid shorting during continued growth and buying during declines.
Second, the current price must be below the mean for buying and above it for selling.

Volatility Levels

We need to know the current market volatility to adjust our targets, stops, and more.

Typically, volatile periods form clusters. New information enters the market, traders use it, there's a price discovery process, and then the market calms down again.

We'll take data from several days and calculate boundaries for five standard deviation levels. Then, we'll plot a chart to see the results.

This is similar to the work I recently shared. However, in that case, I worked with tick data, and this time, I used candlesticks. Link to previous work

You can access the complete code here.

twitter

Classification of Market Regimes Using Standard Deviation

Jungle Sven — Mon, 04 Sep 2023 11:59:09 +0000

Understanding what's currently happening in the market is crucial to make informed decisions. The concept of market regimes helps us gain insight into this. In broad terms, the market can be bullish, bearish, or range-bound. Professionals identify over ten different regimes.

In this article, we'll explore how you can determine market regimes using standard deviation of prices. It allows us to assess how values in a dataset are distributed around the mean.

In our dataset, we have 260,000 rows of data representing tick-by-tick price changes of ETH/USD over approximately 3 days collected via websockets.

df = pd.read_csv(filename, names=['receive_timestamp', 'price'])
df['receive_timestamp'] = pd.to_datetime(df['receive_timestamp'])
df.set_index('receive_timestamp', inplace=True)

First, we need to convert price changes into a logarithmic form, meaning we'll analyze percentage changes instead of regular prices. This helps smooth out volatility and enables easy comparisons across different periods.

df['price'] = df['price'].apply(np.log)

Now, let's calculate the standard deviation of logarithmic prices.

df['std_dev'] = df['price'].rolling(window=100).std()
df['std_dev_ma'] = df['std_dev'].rolling(3000).mean()

Next, we'll define several levels and calculate the boundaries for these levels. Level 0 will correspond to the lowest volatility, with each subsequent group representing higher volatility.

std_dev_ma_threshold_1 = df['std_dev_ma'].quantile(0.2)
std_dev_ma_threshold_2 = df['std_dev_ma'].quantile(0.4)
std_dev_ma_threshold_3 = df['std_dev_ma'].quantile(0.6)

Now, we can create a price chart and mark our levels.

Gray and green zones represent low volatility, while red and black indicate the most volatile segments.

Let's take a closer look at the high-volatility segment.

The faster the price changes, the higher the volatility and standard deviation.

Now, let's examine a chart with a higher resolution.

These findings can be interpreted in various ways. You can enable or disable your trading strategies based on the market's volatility level. I plan to use this data to determine the distance from the mean price at which I'll place my orders as a market maker.

Repository - Link
Twitter - Link

Calculate price stationarity for dYdX exchange.

Jungle Sven — Tue, 22 Aug 2023 06:57:14 +0000

Stationarity helps us to understand what strategies suit a market statistically. Stationarity shows how often prices revert to mean value.

If stationarity is high, we can trade mean-revert strategies. If it is low - trending systems work better.

I will show how to calculate stationarity for all markets in the dYdX exchange.

To make calculations, we need a casual OHLCV. Large timeframes are better for seeing the big picture, as the situation in tiny timeframes changes too fast.

TIMEFRAMES = ['1DAY', '4HOURS', '1HOUR', '15MINS']

After we receive OHLCV, we can calculate stationarity in one line of code with statsmodels!

result = adfuller(df.close)

It is easy to understand the result. If the p-value is less than 0.05, our prices are stationary.

print('p-value: %.2f' % result[1])

Some examples. Stationary prices:

Non-stationary prices:

We can also take p-values from several timeframes and add and then select the largest and the smallest values to find out what markets tend to be more trending.

The most trending markets: $MATIC, $AVAX, $CRV
The least trending markets: $UMA, $CELO, $ETC

The difference between the two groups is between 2 and 3. It can't guarantee a positive result, but it can help to select more optimal markets for a particular strategy or to filter a signal with this data.

GitHub repo - https://github.com/Jungle-Sven/stationarity
Twitter - https://twitter.com/jungle_sven

5 ways to store market data: CSV, SQLite, Postgres, Mongo, Arctic

Jungle Sven — Sat, 19 Nov 2022 21:54:08 +0000

What’s the best way to store market data?

Well, it depends on a combination of factors. Among the most important, I will name dataset size, read and write queries frequency, and desired latency.

So let’s dive in and build an app to perform a considerable amount of CRUD operations and connect it to different databases. We will use plain CSV files, relational databases SQLite and Postgres, and non-relational databases Mongo and Arctic.

Github repo.

We will measure the time of execution of the following operations:

- append 1k records one by one,

- bulk save 1M records,

- read the entire database with 1M records,

- make a single query to the database with 1M records

We will also compare the database size of 1M records datasets.

To produce that 1M records, we will use the synthetic data generator described here.

Let’s make an overview of possible data storage options. CSV files are a fast and comfortable way to work with spreadsheet data, but it’s not great as permanent data storage. SQLite needs no setup and is quick and stable – probably the best option for small projects. Postgres is an open-source production-ready database with lots of use cases. Mongo is a NoSQL alternative that can sometimes be much faster than SQL databases. Arctic is built upon Mongo to make it even more helpful for those who work with market data, as Arctic supports pandas dataframes and NumPy arrays by default.

Now let’s talk about our app.

We will create five connectors to five different data storages. They will consist of four classes: Connector, ReaderApp, WriterApp, and ServiceApp. This time, we will build some connectors from scratch instead of using SQLAlchemy for educational purposes.

The connector class will contain service data like filenames and methods to create tables.

ReaderApp will contain methods to read data from the database and to make a query.

class ReaderApp:
    __metaclass__ = ABCMeta

    @abstractmethod
    def read_all_data(self):
        '''reads all data from file/database'''
        raise NotImplementedError("Should implement read_all_data()")

    @abstractmethod
    def read_query(self):
        '''makes a specific query to file/database '''
        raise NotImplementedError("Should implement read_query()")

WriterApp will save data to the database.

class WriterApp:
    __metaclass__ = ABCMeta

    @abstractmethod
    def append_data(self):
        '''saves data line by line, like in real app '''
        raise NotImplementedError("Should implement save_data()")

    @abstractmethod
    def bulk_save_data(self):
        '''save all data at one time '''
        raise NotImplementedError("Should implement bulk_save_data()")

And ServiceApp will be responsible for clearing databases and statistics, including database size.

class ServiceApp:
    __metaclass__ = ABCMeta

    @abstractmethod
    def clear_database(self):
        raise NotImplementedError("Should implement clear_database()")

    @abstractmethod
    def size_of_database(self):
        raise NotImplementedError("Should implement size_of_database()")

After all those classes are built, we can use them in our main app, MultiDatabaseApp. It will generate synthetic data, perform CRUD operations, measure execution time, and plot charts to visualize results.

The most pythonic way to measure execution time is to use a decorator function. It simply makes something before and after launching the ‘decorated’ part.

def execution_time(func):
        #measures a database operation execution time
        def measure_time(*args, **kwargs) -> dict:
            start_time = time.time()
            response = func(*args, **kwargs)
            execution_time = time.time() - start_time
            response['execution_time'] = execution_time
            return response
        return measure_time

The code is available here.

Now all preparations are ready, and we can start!

The first action is to bulk save 1 million synthetic ticks. Both Postgres and Mongo work slowly. All database server’s settings are default, which could be the reason. Arctic is the leader here!

Both CSV and SQLite are almost as fast as Arctic.

The next test is appending 1000 ticks one by one. And again, Postgres is the worst option. Mongo is the leader here; we can choose it if we need to save data frequently. Arctic, built on Mongo, should have the same speed. Still, I was using VersionStore with 1 million already added data points, so Arctic reads that data each time, appends one, and saves.

Both CSV and SQLite show decent results.

Now let’s check the read operations speed. The first is just a query to read the whole dataset. CSV shows the best result. The operation is complete in less than 1 second! Postgres and Arctic need almost 2 seconds, SQLite – 3 seconds. Mongo is the slowest horse, with 7 seconds.

The next operation to test is a query to select only those rows where the Bitcoin price is less than 20155. SQL databases are fast enough, the same as CSV files. Mongo and Arctic need more time to get data from the database.

Now let’s check our database’s sizes. Arctic is at least two times better than any competitor. What a great result! CSV and SQLite databases are medium sizes, about 40Mb each. Postgres and Mongo need about 100Mb to store the same amount of data, which means that if we are limited with disk space or bandwidth usage, we have to consider other options.

Now let’s have a look at creating operations execution time once more.

Mongo and Arctic can be our choice if we have to perform many write operations on our database. But in fact, CSV and SQLite could be our choice too. Postgres is the slowest option, but there are ways to solve this, like sending async requests to a dedicated database server.

Read operations combined.

Postgres looks like a good choice here. Of course, CSV files are even faster, but CSV is not an actual database. Arctic looks like an excellent option to take into consideration. Mongo is the slowest one.

Some final thoughts. CSV and SQLite are not production-ready choices in many cases, but for a bunch of small/medium projects, they can be easy. Postgres has a slow write time, so it doesn’t look like an option for storing market data. Mongo and Arctic can be good options if we talk about a vast dataset that can not be stored in a plain CSV file.

Github repo with the code.

python #databases #sql #nosql #market-data

What is market data and how to generate it with Python

Jungle Sven — Fri, 28 Oct 2022 10:12:18 +0000

Abstract

Our trading software is definitely going to consume some market data. The most straightforward way to use market data is by analyzing the market and producing some sort of signals for our trading system. But we can also gather a vast amount of data to further build analytical models, train ML algorithms, prepare reports, and more.

Market data is often gathered from data providers, exchanges, and other sources. We will learn how to generate synthetic market data. Later we will receive data from external providers, and we will build a data storage system ourselves for educational purposes.

What is market data

Market data means prices in general. It consists of facts about an occurred trade: name of exchange, name of the asset, price, quantity, trade timestamp, and more. Now we will talk about the two most common types of market data: ohlcv and ticks.

OHLCV

First of all, some definitions. OHLCV is market data combined into a block, it’s not really precise, but it gives traders a general understanding of what happened in the market.

OHLCV corresponds to Open, High, Low, Close, Volume – this is information about trades closed during a period of time(e.g., 1 minute, 15 minutes, 1 hour, 1 day, etc.).

For example, let us say we talk about BTC/USDT market; OHLCV data was gathered for one day period. During such a period, thousands of trades can be processed on large exchanges like Binance. OHLCV gives us only general information: first trade was at a price 19123$(O), the highest price during this period was 19347$(H), the lowest price was 18900$(L), the last price was 19041$(C ), and the sum of all trades during the period was 223500(V).

And, of course, our data is marked with timestamps so we can easily understand when those trades were executed. In our example, data was gathered from October 22, 2021, to October 20, 2022.

Ticks

Tick data is information about each separate trade that happened in an exchange. Those who need more details about the market prefer tick data.

In this example, we connected to DYDX decentralized exchange via WebSocket. Our tick data consists of a timestamp of each trade, symbol(e.g., BTC/USD), side(BUY or SELL) and amount(in BTC).

Synthetic data

As our goal is to understand the pros and cons of different data consumption, storage, and manipulation approaches, we will need a lot of data. We will use synthetic data generation as it’s pretty easy to generate 10 or 10 million data samples with the same function.

First of all, let’s define some basic data classes to work with.

class OHLCV:
    def __init__(self, timestamp, open, high, low, close, volume):
        self.timestamp = timestamp
        self.open = open
        self.high = high
        self.low = low
        self.close = close
        self.volume = volume

class Tick:
    def __init__(self, timestamp, symbol, side, amount, price, exchange):
        self.timestamp = timestamp
        self.symbol = symbol
        self.side = side
        self.amount = amount
        self.price = price
        self.exchange = exchange

Now we will create one more class, DataSample. It will be used to generate synthetic data. We will implement 3 methods for now:

- generate() to generate a single data sample

- build() to generate datasets using generate function

- plot() to visualize our data

class DataSample:
    def __init__(self):
        pass

    def generate(self):
        '''generates 1 data sample'''
        pass

    def build(self):
        '''builds a dataframe of data samples'''
        pass

    def plot(self):
        '''visualizes our dataset'''
        pass

Now we will build 2 more classes – DataSampleOHLCV and DataSampleTicks. They both will have implemented methods generate, build and plot.

Generate function will use Random library so our prices will look more natural. Each next generated price will be slightly different from the previos one.

DataSampleOHLCV and DataSampleTicks code is available in my GitHub repo.

And, finally, one more thing – DataGenerator. It will utilize both DataSampleOHLCV and DataSampleTicks classes and will work as a single interface to generate synthetic data.

class DataGenerator:
    def __init__(self):
        self.ticks = DataSampleTicks()
        self.ohlcv = DataSampleOHLCV()

    def run_ticks(self):
        data = self.ticks.build(n = 10000)
        self.ticks.plot(data)
        return data

    def run_ohlcv(self):
        data = self.ohlcv.build(n = 1000)
        self.ohlcv.plot(data)
        return data

Now lets run the code and see what happens!

Generated OHLCV, 1k samples.

Generated tick data, 10k samples.

The code is available in my GitHub repo.

Microservices

Jungle Sven — Fri, 21 Oct 2022 06:30:04 +0000

Microservice software architecture is something opposite of monolithic architecture. For small projects, monolithic architecture is the most straightforward way to think about its design in general. But any mature project cannot be developed and supported easily if it is a monolith.

The microservice pattern forces developers to divide the project not just into separate modules and classes but into individual tiny apps called microservices. They can be deployed in different data centers, supported by other teams, etc.

Now we will build a simple microservice for our trading software. It will receive our order data via API and save it to the local database. Of course, it is possible to save that data to a local disk. Still, suppose we want to build high-frequency trading software. In that case, we don't want to waste any local resources on logging or statistics, or maybe we want to outsource the development of a feature to a different developers team.

First of all, we will build a basic database connector. We will use the SQLite database for educational purposes. We will create a table of Orders containing six fields: timestamp, username, market, side, size, and price.

Example code:

class Database:
    #this is a DB connector
    #we will use SQLite in this example for simplicity
    def init(self):
        #filename and path to the database are hardcoded for simplicity
        self.connect_to = 'test.db'
    def create_table_orders(self):
        #a func to create our database
        conn = sqlite3.connect(self.connect_to)
        conn.execute('''CREATE TABLE if not exists Orders
        (timestamp TEXT NOT NULL,
        username TEXT NOT NULL,
        market TEXT NOT NULL,
        side TEXT NOT NULL,
        size FLOAT NOT NULL,
        price FLOAT NOT NULL
        );''')
        conn.close()

Database connector will have only one method implemented to save order data to the database.

Example code:

def add_data_orders(self, timestamp, username, market, side, size, price):
    #a func to save orders data
    conn = sqlite3.connect(self.connect_to)
    conn.execute("INSERT INTO Orders (timestamp, username, market, side, size, price) VALUES (?, ?, ?, ?, ?, ?)", (timestamp,
    username, market, side, size, price));
    conn.commit()
    conn.close()

Second, we need an API server. Creating a simple API server with the Flask module in less than 30 lines of code is possible. It will be able to receive HTTP POST requests with order data and save it to the database.

Example code:

@app.post("/API/orders")
def save_orders():
    if request.is_json:
        response = request.get_json()
        DB.add_data_orders(response['timestamp'], response['username'], response['market'], response['side'],  
        response['size'], response['price'])
        return response, 201
        return {"error": "Request must be JSON"}, 415

You can find complete database connector code and API SERVER code on GitHub.

And finally, we need an API connector for our service. Our API connector will use the requests library to make POST HTTP requests to our API server.

Example code:

def generate_request(self, order):
    try:
        response = requests.post(self.api_url, json=order)
        print(response)
    except Exception as e:
        print('generate_request - Exception', e)

You can find the complete API CLIENT code on GitHub.

In ~100 lines of code, we created a database connector, API server, and API client to save order data to the database on the remote server.

The code is available in this Github repo.

Event-driven approach

Jungle Sven — Mon, 17 Oct 2022 15:36:40 +0000

The event-driven approach is a way to think about software architecture. Developing and maintaining a considerable trading application while thinking in procedures and functions paradigm could be inefficient and even impossible.

We can think about trading software as a system that reacts to some random events in the real world. Something happens in the market; prices change, which is an event. We can process it inside our system and produce another event, order, for example, it conditions are met. We can also create a logging or notification event based on our needs.

The event-driven approach helps us better understand what is happening inside the system, maintain control, and support clearer and more efficient software architecture.

Events are the fundamental element of our architecture. You can think of events as data classes or data structures. They can contain a lot of information like the event type, timestamp, specific data, etc.

Example:

class Event(object):
    #base class
    pass

class AccountUpdateEvent(Event):
    def __init__(self, timestamp, username, total):
        self.type = 'ACCOUNT_UPDATE'
        self.timestamp = timestamp
        self.username = username
        self.total = float(total)

Now we will build a simple application that can produce and process events in less than 100 lines of python code!

Our first module is going to make API calls and produce events.

Example code(whole class is available in my GitHub repo):

class GetAccountData:
    def create_event(self, timestamp, username, total):
        self.events.put(AccountUpdateEvent(timestamp=timestamp, username=username, total=total))

The second module processes events.

Example code(whole class is available in my GitHub repo):

class ProcessAccountData:
    def update_account_data(self, event):
        print('Account update received at: ', event.timestamp, 'Username: ', event.username, 'Total balance: ', event.total)

And, finally, our app. It will contain both GetAccountData and ProcessAccountData and a queue of events.

Example code(whole class is available in my GitHub repo):

class App:
    def __init__(self):
        self.events = Queue()
        self.get_data_account = GetAccountData(self.events)
        self.process_data_account = ProcessAccountData()

This app contains a loop to process events. Once a new event is in our queue, we take it out and process it.

Example code(whole class is available in my GitHub repo):

def event_loop(self):
       while True:
            try:
                event = self.events.get(False)
            except Exception as e:
                time.sleep(1)
                break

            else:
                try:
                    if event is not None:
                        if event.type == 'ACCOUNT_UPDATE':
                            self.process_data_account.update_account_data(event)

                except Exception as e:
                    print('event_loop error:', e)

This is an example of a simple event-driven application. You can find the source code in my GitHub repo.

Asynchronous programming

Jungle Sven — Fri, 14 Oct 2022 06:35:21 +0000

It would be best if you had at least a basic understanding of asynchronous programming to build fast-reacting trading software.

The problem with the synchronous approach used most of the time is that our program must wait for data input from dedicated sources before proceeding to further actions. Connecting to WebSockets and receiving tick data updates or open order updates from exchanges using synchronous software is nearly impossible.

Asynchronous programming allows us to skip waiting for data input and proceed to the control stream or data processing stream. This approach radically improves our software speed and performance.

We will use asyncio python library for building an asynchronous application.

We need to learn a few concepts to start building asynchronous software.

First, our functions are marked as asynchronous with async word, like in JavaScript. Example:

async def my_function()

Second, we use await word to tell the program where it can switch control from one stream to another. Example:

await asyncio.sleep(0)

This line of code does nothing but tell our program not to wait for data input or some long calculations, so our program can switch to another task.

Third, in building asynchronous software, we operate not only functions but tasks. A task can contain one or more functions inside.

Example:

async def input_func():
    pass


async def input_task():
    await asyncio.sleep(0)
    await self.input_func()

And, finally, loops. Our tasks are run inside loops, which can be called ‘control streams’.

Example:

ioloop = asyncio.get_event_loop()
tasks = [ioloop.create_task(input_task()), ioloop.create_task(another_task())]
wait_tasks = asyncio.wait(tasks)
ioloop.run_until_complete(wait_tasks)

This is an example of a simple asynchronous application. You can find it in this GitHub repo.

Building efficient crypto trading software with python

Jungle Sven — Tue, 11 Oct 2022 09:12:05 +0000

Hello and welcome to this short list of articles where I will talk about the modern approach to building production-grade trading software with python programming language.

Python is widely used for its simplicity and clean, readable code. More than one million software developers can understand and support the code written in python.

But python is known for some disadvantages, such as speed. You can ignore this disadvantage most of the time as most libraries used for trading purposes use code snippets written in C and are fast enough for most common tasks.

We will discuss three main concepts: asynchronous programming, event-driven architecture, and microservices architecture.

As far as our software will use different data sources, API services, and more, we will have to make it asynchronous, so we will not wait for a data lag from any remote services. Asynchronous execution is a must.

The event-driven approach helps us better understand and control what is happening in the system, which works fast.

Microservices architecture makes it easier to develop and support projects with thousands of lines of code by giving us a chance to focus on a single problem which can be way harder with a monolithic architecture.

If you are interested in learning about building crypto trading software, follow this channel for more content.