DEV Community: Brian Ting

Software Engineering in 2026: A View From the Server Room

Brian Ting — Thu, 01 Jan 2026 04:55:36 +0000

I read Ben Congdon's article "Software Engineering in 2026" and found myself nodding along to many of his points. But I also noticed something: the conversation around AI and software engineering often feels like it's happening in a different world from mine.

I'm a Full-Stack Engineer managing distributed systems across 15+ production sites in Malaysia. My daily work isn't only about building shiny new features, but also about keeping things running, handling database migrations at 2 AM, and making sure our 99%+ uptime stays that way. I am basically wearing multiple hats: writing specs, developing products, code review, deliver products, and ensure everything works without issue.

Ben's article got me thinking: What does the AI revolution in software engineering look like from the server room?

Where I Agree: AI Has Changed the Game

Let me be clear first. AI tools have genuinely changed how I work. The "marginal cost of producing high quality code has gone down," as Ben puts it. This is real.

Here's where I've seen the biggest impact in my daily work:

Writing boilerplate code. Setting up a new FastAPI endpoint with proper validation, error handling, and documentation? What used to take 30 minutes now takes 5. AI handles the repetitive parts while I focus on the business logic.

Code reviews for patterns. When reviewing AI-generated code, I've found that AI is surprisingly good at following established patterns. It rarely invents weird solutions when you give it clear examples.

Documentation. Writing docstrings, API documentation, and README files used to feel like a chore. Now it's almost automatic. I review and edit, but the heavy lifting is done.

So yes, the productivity gains are real. But here's where my experience starts to differ from the mainstream narrative.

The Part Nobody Talks About: Operating Systems

Ben makes an important observation that I wish more people would pay attention to:

"Operating" systems, from what I've seen, has for now been least impacted by LLMs.

This matches my experience exactly. And I'd argue this is the most important part of software engineering that gets overlooked in AI discussions.

When you manage 15+ production sites, you learn quickly that writing code is just the beginning. The real challenge is what comes after. Deployment. Monitoring. Debugging production issues at scale. Handling that one edge case that only appears when three specific conditions align during peak hours.

AI can help me write a database migration script. But can it tell me whether I should run that migration during lunch hour or after midnight? Can it predict how the migration will affect query performance across sites with different data distributions? Can it handle the rollback if something goes wrong?

Not yet. Maybe not for a while.

What Production Experience Teaches You

There's a kind of knowledge you only get from keeping systems alive. Let me share some examples.

Database decisions compound over time. Last year, I made a choice about how to structure a particular table. It seemed like a small decision then. Few months later, that decision affected query performance when the product scales up. AI can suggest schema designs, but it doesn't understand your specific data access patterns, growth projections, or the quirks of your production workload.

Network reality differs from theory. I work in Sarawak, where network conditions can be... interesting. Our systems need to handle unstable connections, high latency, and occasional outages. This isn't in any training data. You learn it by debugging failed requests at 3 AM and building systems that gracefully degrade.

Uptime requires human judgment. When something breaks in production, the first question isn't "what's the fix?" It's "how bad is this?" You need to decide: Do we roll back immediately? Can we apply a quick patch? Should we wake up other team members? These decisions require understanding the business impact, not just the technical problem.

Why Backend Work Feels Different

Ben mentions that "LLMs seem to grok frontend particularly well." I've noticed this too, and I have a theory about why.

Frontend work often has immediate, visible feedback. You change the code, you see the result. This makes it easier to iterate with AI assistance. You can quickly verify if the AI's suggestion works.

Backend work is different. The consequences of your decisions often don't show up immediately. A poorly designed API might work fine today but cause scaling problems in six months. A database index choice might seem irrelevant until you have 10 million rows. A caching strategy might work in development but fail under production load.

This delayed feedback loop makes AI assistance trickier. By the time you realize the AI's suggestion was suboptimal, you've already built a lot on top of it.

The Skills That Matter More Now

So what should backend engineers focus on in 2026? Based on my experience, here's what I'm investing in:

System design and architecture. Ben talks about "crisp human-guided abstractions," and I think this is exactly right. The ability to design systems that are maintainable, scalable, and clear becomes more valuable when code is cheap. Anyone can generate code. Not everyone can design systems that work well over time.

Operational excellence. Understanding monitoring, observability, incident response, and debugging in production. These skills are hard to automate because they require deep context about your specific systems and business needs.

Understanding trade-offs. Every technical decision involves trade-offs. Consistency vs. availability. Performance vs. maintainability. Speed vs. reliability. AI can list options, but understanding which trade-off is right for your situation requires experience and judgment.

CI/CD and deployment practices. Ben emphasizes this too, and I agree completely. When AI is generating more code, your ability to test, validate, and safely deploy that code becomes critical. Investing in solid CI/CD infrastructure pays off even more now.

The "Build vs. Operate" Gap

Here's something I think about a lot. Ben asks whether falling code costs will shift the "build vs. buy" calculation. He notes that operating costs haven't fallen the way development costs have.

This creates an interesting situation. It's easier than ever to build something. It's not any easier to run it reliably in production. This gap will only grow.

I expect this means operational expertise becomes more valuable, not less. Companies can spin up new systems faster, but they still need people who can keep those systems running. If you're a backend engineer, this is good news. The skills you've built around production reliability aren't being automated away.

Looking Forward

I don't want to sound like I'm against AI tools. I use them daily. They've made me more productive. But I think we need a more balanced conversation about where AI helps and where human expertise still matters.

Software engineering has always been about more than writing code. It's about understanding problems, making trade-offs, and building systems that work in the real world. AI is changing how we write code, but it hasn't changed those fundamentals.

For those of us working in backend and infrastructure, the message I take from 2025 going into 2026 is this: Keep building your operational skills. Keep learning about system design. Keep gaining production experience. These skills are becoming more valuable, not less.

And if you're managing distributed systems across multiple sites while AI handles some of your boilerplate code? You're in a pretty good position for whatever comes next.

What's your experience with AI tools in backend or infrastructure work? I'd love to hear from others who work in operations-heavy roles. Drop a comment below.

Flutter State Management Made Simple: Mastering Riverpod in Practice (Part 2)

Brian Ting — Wed, 22 Jan 2025 02:06:08 +0000

Implementation Deep Dive

Riverpod’s true power shines when you start implementing it in real-world scenarios. Let’s move beyond theory and explore how to wield this framework effectively—from basic setups to advanced patterns.

1. Basic Implementation

The Gateway: ProviderScope

Every Riverpod-powered app starts with ProviderScope, a widget that injects the state container into your app. Wrap your root widget with it:

void main() {  
  runApp(  
    ProviderScope(  
      child: MyApp(),  
    ),  
  );  
}

This acts as the backbone for all providers in your app. Providers are declarative, reusable objects that manage and provide state or dependencies across a Flutter application, allowing efficient and clean state management.

Three Pillars of Providers

1. `StateProvider`: Ideal for ephemeral state (e.g., counters, switches).

   final counterProvider = StateProvider<int>((ref) => 0);

Why this works: Exposes a simple state getter/setter.

2. `StateNotifierProvider`: Manages complex business logic with immutable state.

   class TodoNotifier extends StateNotifier<List<Todo>> {  
     TodoNotifier() : super([]);  
     void addTodo(Todo todo) => state = [...state, todo];  
   }  
   final todoProvider = StateNotifierProvider<TodoNotifier, List<Todo>>((ref) => TodoNotifier());

Why this works: Decouples logic from UI, enabling testability.

3. `FutureProvider`: Handles async operations like API calls.

   final weatherProvider = FutureProvider<Weather>((ref) async {  
     final location = ref.watch(locationProvider);  
     return await WeatherAPI.fetch(location);  
   });

Why this works: Automatically manages loading/error states.

Example: From setState to Riverpod—A Paradigm Shift

Compare a counter implementation:

// Traditional setState  
class CounterPage extends StatefulWidget {  
  @override  
  _CounterPageState createState() => _CounterPageState();  
}  

// Riverpod approach  
class CounterPage extends ConsumerWidget {  
  @override  
  Widget build(BuildContext context, WidgetRef ref) {  
    final count = ref.watch(counterProvider);  
    return ElevatedButton(  
      onPressed: () => ref.read(counterProvider.notifier).state++,  
      child: Text('$count'),  
    );  
  }  
}

Riverpod eliminates the need for StatefulWidget by managing state outside the widget tree. State becomes globally accessible through WidgetRef, making it easier to access and modify from anywhere in your app while maintaining clean architecture. This approach reduces boilerplate code and separates state management concerns from your UI logic.

2. Advanced Scenarios

Dependency Injection Made Simple

Think of providers as containers for your services. Here's how to manage API calls cleanly:

// Define your API client provider - a single source of truth
final apiClientProvider = Provider<ApiClient>((ref) => ApiClient());

// Use it to fetch user data
final userProvider = FutureProvider<User>((ref) async {
  final client = ref.watch(apiClientProvider);
  return client.fetchUser();
});

// Usage in a widget
class UserProfile extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final user = ref.watch(userProvider);
    return user.when(
      data: (data) => Text(data.name),
      loading: () => CircularProgressIndicator(),
      error: (error, stack) => Text('Error: $error'),
    );
  }
}

Key takeaway: Providers create a clean dependency injection system that makes testing straightforward - simply override providers with mocks without changing your production code.

State Persistence

Save app settings automatically across restarts by pairing StateNotifierProvider with HydratedMixin for automatic serialization, requiring minimal additional code:

// Define your settings state
class Settings {
  final ThemeMode theme;
  Settings({required this.theme});

  factory Settings.defaults() => Settings(theme: ThemeMode.system);

  Settings copyWith({ThemeMode? theme}) =>
      Settings(theme: theme ?? this.theme);

  factory Settings.fromJson(Map<String, dynamic> json) =>
      Settings(theme: ThemeMode.values[json['theme'] as int]);

  Map<String, dynamic> toJson() => {'theme': theme.index};
}

// Create a persistent provider
final settingsProvider = StateNotifierProvider<SettingsNotifier, Settings>(
  (ref) => SettingsNotifier(),
);

class SettingsNotifier extends StateNotifier<Settings> with HydratedMixin {
  SettingsNotifier() : super(Settings.defaults());

  void updateTheme(ThemeMode theme) => state = state.copyWith(theme: theme);

  @override
  Settings fromJson(Map<String, dynamic> json) => Settings.fromJson(json);

  @override
  Map<String, dynamic> toJson(Settings state) => state.toJson();
}

// Usage in a widget
class ThemeToggle extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final settings = ref.watch(settingsProvider);
    return Switch(
      value: settings.theme == ThemeMode.dark,
      onChanged: (isDark) => ref.read(settingsProvider.notifier)
          .updateTheme(isDark ? ThemeMode.dark : ThemeMode.light),
    );
  }
}

Combining Providers

Calculate values based on multiple states:

// Shopping cart example
final cartItemsProvider = StateNotifierProvider<CartNotifier, List<CartItem>>(...);
final discountProvider = StateProvider<double>((ref) => 0.0);

final cartTotalProvider = Provider<double>((ref) {
  final items = ref.watch(cartItemsProvider);
  final discount = ref.watch(discountProvider);

  final subtotal = items.fold(0.0, (sum, item) => sum + item.price * item.quantity);
  return subtotal * (1 - discount);
});

Key takeaway: Create reactive computed states that automatically update when their dependencies change - perfect for derived values like totals, filtered lists, or complex calculations.

Parameterized Providers with Family

Fetch different data instances using the same provider:

final productProvider = FutureProvider.family<Product, String>((ref, productId) async {
  final client = ref.watch(apiClientProvider);
  return client.fetchProduct(productId);
});

// Usage in a widget
class ProductTile extends ConsumerWidget {
  final String productId;

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final product = ref.watch(productProvider(productId));
    return product.when(
      data: (data) => ListTile(title: Text(data.name)),
      loading: () => Shimmer(),
      error: (error, _) => ErrorTile(),
    );
  }
}

When to use: Perfect for scenarios where you need multiple instances of similar data, like fetching different products by ID or managing user-specific states.

3. Common Pitfalls & Best Practices

Reactivity Traps

Don’t: Overuse ref.read in builders—it breaks reactivity.

  // 🚫 Avoid  
  ref.read(counterProvider.notifier).state++;  

  // ✅ Prefer  
  ref.watch(counterProvider);

Do: Use autoDispose to avoid memory leaks:

  final tempDataProvider = StateProvider.autoDispose<int>((ref) => 0);

Optimize Rebuilds with select

Prevent unnecessary widget rebuilds by listening to specific properties:

final userName = ref.watch(userProvider.select((user) => user.name));

Only rebuilds when user.name changes, not the entire user object.

4. Testing

Building on our earlier discussion of dependency injection, here's how to put provider overrides into practice:

testWidgets('Displays mocked user', (tester) async {  
  await tester.pumpWidget(  
    ProviderScope(  
      overrides: [  
        userProvider.overrideWithValue(  
          AsyncValue.data(User(name: 'Test User')),  
        ),  
      ],  
      child: MyApp(),  
    ),  
  );  
  expect(find.text('Test User'), findsOneWidget);  
});

No complex mocking setup—swap dependencies at the provider level.

Wrapping Up

Riverpod isn't just about managing state—it's about architecting scalable, testable, and maintainable apps. By embracing providers, families, and reactive patterns, you'll unlock a toolkit that grows with your app's complexity.

As you continue your Flutter development journey, remember that solid state management isn't just a technical choice—it's an investment in your app's future growth and your team's productivity. I hope these articles have equipped you with the knowledge and confidence to build more robust Flutter applications with Riverpod.

Flutter State Management Made Simple: Why Riverpod Should Be Your Next Choice (Part 1)

Brian Ting — Wed, 22 Jan 2025 02:05:58 +0000

Understanding Riverpod and Its Value

State management in Flutter has always been a polarizing topic. From setState to complex architectures like BLoC, developers juggle trade-offs between simplicity, scalability, and maintainability. Enter Riverpod—a framework that reimagines state management as a holistic solution for reactivity, caching, and dependency injection. Let’s unpack why it’s becoming the go-to choice for Flutter developers.

1. What is Riverpod? The Swiss Army Knife of Flutter State Management

Riverpod is a reactive caching and state-management framework designed to solve the shortcomings of its predecessor, Provider, while introducing a robust set of tools for modern app development. Unlike traditional state management libraries, Riverpod operates independently of Flutter’s widget tree, making it usable in pure Dart projects.

Key Features:

Compile-Safe by Design: Say goodbye to runtime exceptions caused by missing providers. Riverpod’s compile-time checks ensure your code is validated before it runs.
Declarative Reactivity: State changes propagate automatically through a unidirectional data flow, reducing side effects.
Flexible Provider Ecosystem: From StateProvider for simple counters to FutureProvider for async operations, Riverpod offers tailored solutions for diverse use cases.
Context-Free: No reliance on Flutter’s BuildContext, enabling cleaner logic separation.

Created by Remi Rousselet (the mind behind Provider), Riverpod is its spiritual successor—addressing legacy pain points while introducing powerful new paradigms.

2. Why Riverpod?

Imagine building a house. You could use nails and a hammer, but a pneumatic nail gun would save time, reduce errors, and scale for larger projects. Riverpod is that nail gun for Flutter apps.

Scalability: Riverpod shines in large apps. Its decoupled architecture lets you manage state globally without tangling it into the widget hierarchy—ideal for enterprise apps or long-term projects.
Testability: Override dependencies effortlessly. Swap a live API client with a mock during testing, all without touching the widget tree.
Architecture Agnostic: Whether you follow MVVM, Clean Architecture, or something custom, Riverpod adapts to your structure.
Tooling: Integrated with Riverpod DevTools, debugging becomes a visual, intuitive process.

Comparison with Provider:

While Provider revolutionized state management, it relied on BuildContext and occasionally threw runtime errors. Riverpod eliminates these issues, offering a safer, more flexible foundation.

3. Riverpod vs. Alternatives: A Pragmatic Choice

How does Riverpod stack up against popular alternatives? Let’s break it down:

Feature	Riverpod	BLoC	GetX	Redux
Compile Safety	✅	❌	❌	❌
Boilerplate	Low	High	Low	High
Testability	Easy	Medium	Easy	Hard
Context-Free	✅	❌	✅	❌

BLoC/Cubit: Powerful but requires boilerplate (events, states, blocs). Riverpod simplifies reactivity with fewer layers.
GetX: While easy to use, it lacks compile-time checks, risking subtle bugs.
Redux: Predictable but verbose. Riverpod’s granular reactivity reduces unnecessary rebuilds.
InheritedWidget: Scalability nightmare. Riverpod provides global access without coupling to widgets.

**4. When NOT to Use Riverpod?**

Riverpod isn’t a silver bullet. Consider skipping it if:

Your app is trivial: A single-screen demo with minimal state might not justify the setup.
Your team is already proficient: If your squad masters BLoC or GetX, switching mid-project could hinder productivity.

Wrapping-up

Part 1 balances theory with actionable insights, preparing you to evaluate Riverpod’s role in your next project. Whether you’re rebuilding an enterprise app or starting fresh, Riverpod’s blend of safety and flexibility makes it a compelling choice.

In Part 2, we’ll explore hands-on implementations—from basic counters to advanced dependency injection and state persistence. You’ll learn how to harness StateNotifierProvider, mock dependencies in tests, and avoid common pitfalls.

Deploying Flutter Web App on Live Server

Brian Ting — Thu, 08 Feb 2024 01:48:31 +0000

So you have your very first Flutter web app developed, tested and everything works just like what your customer wanted. It's time to bring your newly-developed app to live. Here's how to do it.

Note: The following steps will be carried using Windows 11. Some of the steps may differ on older Windows/Linux/MacOS but ultimately it should work as well.

Here's the breakdown of the article:

Build Your App
Install Necessary Software
[Optional] Serve Your Web App using Express
Configure Firewall and Port Forwarding
[Optional] Configure Backend for CORS

Build Your App

First thing first, our app need to be built for production. Fire up your Terminal/PowerShell in your project directory, and enter the command:

PS flutter build web

Flutter will use dart2js compiler to compile your project into a web project. The compiled program will be inside your_project_directory/build/web/. This directory can be copied to your live server.

Install Necessary Software

A web server is needed to serve the web app. You can use whatever web server of your choice. However in this example, I will use Express to serve the web app. Based on their website:

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

To use Express, Node.js is needed. Download and install Node.js here.

After Node.js is installed, use npm to install Express. Open up new Terminal/PowerShell window and enter:

PS npm install express

[Optional] Serve Your Web App using Express

You can skip this step if you use your own web server of choice. If you followed my steps above, you can keep reading.

To serve the web app using Express, you need to write a script to tell Node.js which framework to use, where to host, and some network parameters. In your compiled web app directory, create a JavaScript file and write:

// Define the variables
const express = require('express');
const app = express();
const PORT = 60000;
const HOST = '0.0.0.0';

// Serve static files from the project directory
app.use(express.static('.'));

// Listen to the network
app.listen(PORT, HOST, () => {
    console.log(`Server running on port http://${HOST}:${PORT}`);
});

I will explain a bit on this file: in this case we use port 60000 for our web app, and host '0.0.0.0' means it allows all types of connections to access to this web server. The Express will use current directory to serve static files.

This is the minimal script that just enough to make it works. Save this file as 'server.js' then open up Terminal/PowerShell again in current directory and enter the command:

PS node .\server.js

Configure Firewall and Port Forwarding

We have one more step to bring the web app online, which requires us to configure firewall and port forwarding so the outside connection can access the app.

Open Up a Port

Open up your Windows Defender Firewall from Start, then go to Advanced Settings (Highlighted).

It should pop up a new window. In the left pane, select Inbound Rules, and then create a new rule (Highlighted).

Our rule type should be Port, then apply to TCP, then points to port 60000 (depends on your configuration for the web server).

In the next step, allow the connection, set up your rule name and save it.

Port Forwarding

Access to your router setting and create a port forwarding rule to point to your web server's port (same as your newly-created firewall rule). It should roughly looks something like this:

The Local IP should be your live server's local IP.

Voila! Your server that runs Flutter Web App is now live to the public!

[Optional] Configure Backend for CORS

It important to know that Flutter Web App requires to have CORS (Cross-Origin Resource Sharing) support, as modern web browsers are enforcing CORS as a part of modern web standards.

If your web app is not connecting with cloud services like Firebase but with your own API backend, you should make sure your backend has implemented CORS support, else it will not work (as web browser will refuse to establish connection with backend).

I will use FastAPI as example, it must have the following:

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware


# Create a FastAPI instance
app = FastAPI()


# CORS Origins
# Put your own URL/Dynamic DNS addresses
origins = [
    "http://127.0.0.1:60000",
    "http://mydyndns.ddns.net:60000",
    "https://mydyndns.ddns.net:60000",
]

# Configure CORS
app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Restart FastAPI, and it will only accept any connection from the specified URL and port.

Thanks for Reading ;)

Hope this serves as a useful guideline for anyone who wanted to bring their first Flutter Web App online.

Communicate with Microsoft SQL Server that works on Flutter app compiled for multiple platforms

Brian Ting — Wed, 20 Dec 2023 01:49:59 +0000

Suppose you envision that Flutter is the future, especially its capability to be compiled for many platforms through one codebase, which may greatly save up the cost of development for your own good. You have existing customers, and customers will also eventually move on to adapt new technology, that means you also have to keep up the market trend to satisfy your customers' needs.

Even though you wanted to deliver a revamped app to your customers, but in reality you have to face one important problem: customers may love to use your new app, but customers most likely do not want to pay a high price to change their database. In their perspective, their existing database just works for many years, there is no reason to 'upgrade' their database if it does not break. Here I mean, they are using SQL Server, and most likely they are using the Microsoft one.

Background

I have spent an extended amount of time to search for compatible plugins for Flutter that is able to communicate with Microsoft SQL Server. Sadly, though Flutter has a trusty sqflite plugins, and the same author has also wrote drift plugins (they're both great, I have used them), but dealing with SQL server is still a lacking part in Flutter ecosystem. Although drift does has remote library to deploy a remote SQL server, but it requires the other end to have drift installed too (correct me if I'm wrong). I don't think I would spend much time to setup drift for an existing, well-configured SQL server.

In the time of writing, there is one working plugin for Flutter that able communicate with MSSQL protocol, which is sql_conn. I thought I found a saviour, until I saw this:

I was like, whaaaat? Android only, other platforms are out of luck. I thought of forking the project on GitHub and add support to other platforms as well, but it is not as easy as I thought.

What To Do?

If there is no way I can find the off-the-shelf plugin to achieve this, shall I abandon my visionary Flutter project? After a serious consideration, I do not think I will opt for other frameworks. So, I thought of another approach: writing my own API backend as middleware.

Middleware -- FastAPI + SQLAlchemy

I am familiar with Python myself, so choosing to write a middleware in Python is a no-brainer for me. I stumbled upon something called "FastAPI" thingy which claimed to be a verrryyyyy fast API server, and good-olde SQLAlchemy with pyodbc that provides the protocol to communicate with MSSQL.

So, shall we?

Starting The Project

First thing first, fire up your terminal and install the required libraries.

python -m pip install fastapi sqlalchemy pyodbc

Then, we may create a python file, and write something like this:

from fastapi import FastAPI
from sqlalchemy import create_engine, text
from sqlalchemy.orm import sessionmaker

config = {
  "sqldbIP": "192.168.16.99",
  "sqldbPort": "1433",
  "sqldbDB": "RMS",
  "sqldbUserId": "test2",
  "sqldbPass": "test2",
  "MachineId": "1"
}

app = FastAPI()

# Start of program, connecting to DB
conn_string = f"mssql+pyodbc://{config['sqldbUserId']}:{config['sqldbPass']}@{config['sqldbIP']}:{config['sqldbPort']}/{config['sqldbDB']}?driver=ODBC+Driver+17+for+SQL+Server"
connection = create_engine(conn_string)

Session = sessionmaker(bind=connection)
session = Session()

The above code tells the Python to import the necessary libraries, then we write a dictionary called config that defines where the SQLAlchemy should connect to.

We initialise the FastAPI app by calling app = FastAPI(), then define the connection string conn_string.

First we need to pass the pyodbc driver mssql+pyodbc so it can communicate with MSSQL, then follow the connection format, and lastly pass the custom driver driver=ODBC+Driver+17+for+SQL+Server.

We may need to create an engine and also session for us to execute SQL queries.

Queries

Now, we are going to write some pure SQL queries to interact with SQL Server. I would suggest you to create a file specifically for querying and not mix with the main Python file, so you can maintain the code more easily in the future when the project scales up.

Let's start with the most basic query:

SELECT * FROM <table_name>

This tells the SQL Server to show all records available in that particular table. Let's turn it into Python script:

# Import necessary libraries
from sqlalchemy import text
import json

def retrieve_data_from_table(session):
    query = text("SELECT * FROM employee_table")
    cursor = session.execute(query)

    employee_id = []
    employee_name = []
    json_data = {}

    for row in cursor.fetchall():
        employee_id.append(row[0])
        employee_name.append(row[1])

    json_data = {id: employee_id, name: employee_name}

    cursor.close()
    session.close()

    return json_data

As you can see, I defined a function specifically to retrieve the data from a table, and everything is pretty much a hard-code to make sure it works.

I used text method from sqlalchemy library to write the query, because this method can produce a well-formatted query for sqlalchemy to interact with the database.

The cursor will store the data fetched from the database after calling execute method from the database session, then I used a for loop to populate the data into result list, lastly store the result into json_data dictionary. This should can be directly being used to output the API calls.

Lastly, before return the json output, don't forget to close the connection.

So you can imagine, whatever queries that MSSQL supports, you can just throw them into the text() method, execute it and make sure to insert the results into your Python dictionaries. You can structure your Python dictionary as you please, in the end it will return the dictionary as json to your client-end.

Paths

We need to have paths for our client side to communicate with the backend. Defining path is very simple in FastAPI. Here's an example:

@app.get("/")
async def home():
    return retrieve_data_from_table(session)

First, we need to use the decorator @app.get("/"), which app is the FastAPI instance, and tell the FastAPI that this path should use HTTP GET operation. Then, we define an asynchronous function (since of FastAPI's nature) home(), and call the query function retrieve_data_from_table(session) to retrieve our data from SQL server. The output of this path when being accessed by client-side Flutter app will be json_data we defined in the query function.

If you have query parameters, you can give the parameters to the async function like how you give parameters in normal functions, and then pass the parameters in your function call.

Additionally, if you want to perform HTTP POST operation (when Flutter user submit a data), you can use the post method:

# Import necessary libraries
from fastapi import Request

@app.post("/submit")
async def submit(request: Request):
    data = await request.body()
    data_str = data.decode()
    data_json = json.loads(data_str)

    return submit_order(session, data_json)

Notice that I use post instead of get on the decorator this time. The request parameter is needed so the FastAPI can decode the data and send to the submit_order function that performs either CREATE, UPDATE, DELETE SQL queries as you define it yourself.

On Flutter's Side

We're settled on backend side (Python), now we're going to our client side (Flutter).

Create an empty Dart file, and put some code into it:

import 'package:http/http.dart' as http;
import 'dart:convert';

const config = {
  "apiUrl": "10.0.2.2:8000",  // Connect to localhost for Android emulator
};

Future<Map<String, dynamic>> fetchEmployeeData() async {
  var url = Uri.http(config["apiUrl"]!, '/');
  final response =
      await http.get(url);

  if (response.statusCode == 200) {
    // If the server returns a 200 OK response, parse the JSON.
    Map<String, dynamic> employeeData = json.decode(utf8.decode(response.bodyBytes));
    return employeeData;
  } else {
    // If the server returns an error response, throw an exception.
    throw Exception('Failed to load employee data.');
  }
}

Make sure the http package is added into pubspec.yaml to make things work. I added some comments in the code so you can understand how it works. Basically, apiUrl is defined so Flutter app can connect to the FastAPI server using http.get(url) method. When the response status code is 200 (meaning OK), the app will decode the json (it's Python dictionary we defined as json_data before) as Dart's Map variable employeeData. Finally, you use this employeeData to display your data.

If you have query parameters, I encourage you can take a short read on Uri.http reference about how to pass the query parameters.

Additionally, if you want to submit the user input to the server (which is POST instead of GET), it should be like this:

Future<bool> submit(
    {required List<dynamic> data}) async {
  var url = Uri.http(config["apiUrl"]!, '/submit');
  var headers = {'Content-Type': 'application/json'};
  final response = await http.post(
    url,
    headers: headers,
    body: json.encode({
      'data': data,
    }),
  );

  if (response.statusCode == 200) {
    bool submitStatus = true;
    return submitStatus;
  } else {
    throw Exception('Submission Failed: ${response.reasonPhrase}');
  }
}

For this time, notice that there is required parameters in the function submit(), which contains the data to submit to the server, and a headers is needed for POST operation, and in the end we use the http.post method to perform POST operation.

In this case, I return a boolean variable submitStatus to tell the app whether the POST operation is successful, but you can modify the function yourself that suits your needs.

Start the Server

After everything is setup, fire up your FastAPI server. FastAPI uses uvicorn as their default development server, and you can run this command in the terminal:

uvicorn main:app --reload

This tells uvicorn to run the app instance, and able to reload the server every time the code changes. The default port is 8000, but you can specify the uvicorn to use which port you desire by passing --port <integer>, and you also need to change the target port in Flutter's code in that case.

The End

Phew! It's a long article, but through this your Flutter app can communicate with SQL Server no matter the app is compiled to which platform of choice. It's platform-agnostic.

If you found a better solution, do leave a comment and let me know too! Thank you.

Some Code Refactor Tips for Junior Developers

Brian Ting — Wed, 10 Feb 2021 05:22:30 +0000

When starting the first career of being a software developer, apart from the knowledge gained from university or college, there is some more things needed to be aware of.

There was no requirement to write a good, maintainable code during the course works, we all only wanted to get the things done and pass the course. However, being in a career often means you will work in a team, and the project being worked on often needs to consider the project maintainability. One of it is to know how to refactor the code.

Here, I will give few examples in Python-like syntax and elaborate them. This is not representing any web framework, just for the ease of read.

Tip 1: Functions

Suppose you have a web app, and to write a feature that lets users to generate a table of data, let's say the staffs who attended the company annual dinner, and at the same time it counts the number of people who got the lucky draw.

Instead of having this:

def generateTable():
  # Get data from a database named 'staffDB', 
  # and get the records who attended annual dinner
  data = staffDB.totalStaffs.filter(attended_annual_dinner=true)

  # Write a formatted table and dump data in
  table = TableObject(
    header1="Name",
    header2="Got Lucky Draw?"
  )

  table.header1.data = data.name
  table.header2.data = data.lucky_draw

  # Count the total number who got lucky draw
  lucky = data.lucky_draw
  who_got_lucky_draw = 0

  for got_lucky_draw in lucky:
    if got_lucky_draw == "yes":
      who_got_lucky_draw += 1

  # Ultimately, pass every data here to the webpage
  return('annual_dinner.html', 
    data=data, table=table, 
    who_got_lucky_draw=lucky_counts)

You can see, a function that carries three tasks:

Get data from database
Generate a table
Count who got lucky draw

Although it does not seems complicated here, but in real world project this kind of writing style always ends up hundreds line of code.

It can be done in much simpler form:

def getAttendingStaffs():
  # Get data from a database named 'staffDB', 
  # and get the records who attended annual dinner
  data = staffDB.totalStaffs.filter(attended_annual_dinner=true)

  table = generateTable(data.name, data.lucky_draw)
  who_got_lucky_draw = getLuckyCount(data.lucky_draw)

  return('annual_dinner.html', 
    data=data, table=table, 
    who_got_lucky_draw=lucky_counts)

def generateTable(name, lucky_draw):
  # Write a formatted table and dump data in
  table = TableObject(
    header1="Name",
    header2="Got Lucky Draw?"
  )

  table.header1.data = name
  table.header2.data = lucky_draw

  return table

def getLuckyCount(lucky_draw):
  # Count the total number who got lucky draw
  who_got_lucky_draw = 0

  for got_lucky_draw in lucky_draw:
    if got_lucky_draw == "yes":
      who_got_lucky_draw += 1

  return who_got_lucky_draw

This one splits into three functions, each one performs single task. Only when the getAttendingStaffs() function is called, it will also call two other functions and pass the required parameters in.

Although this results more line of code in total, but it surely make the code tidier, and easier to navigate when you need to modify the function.

Take an example in real world project, there is a bug in generating the table. The former style makes you search through a long line of code that wraps everything into a function, and the code looks messier in overall; the later style you can only focus on that particular function, better focus.

Tip 2: Source files based on purpose

The idea of this one is similar to the one above, but make it in the file-level.

In other words, create source files based on its scope of job. Instead of one source file performing few jobs, separate the jobs into few source files.

For example, you have a blog website, and users can have account to write their blog posts. In this case, you can create a few source files, where one stores all the global constants, one does the job of handling user account information, one does the job of handling posts. Lastly, you have a main source file (as entry point) referring those files and they work together.

Doing so keeps the logic away from a single file. So, in future maintenance, perhaps you want to have a new feature that allows users to upload an image to a post, just mess with that source file, the others are unaffected.

Tip 3: Negation IF

Often we need to write a conditional statement to control how an application behaves. If you are writing a simple conditional statement, using negation statement is often recommended.

Well, this does not really make the code significantly less cluttered, but apart from what textbook taught (a conventional if-else style), we can make the code looks a little bit cooler.

Instead of this:

def someFunction():
  if somethingPositive:
    # Do this
    return(someValue)
  else:
    # Do that
    return(otherValue)

Make it like this:

def someFunction():
  if somethingNegative:  # Negation IF
    # Do this
    return(someValue)

  # Proceed to do desired tasks

Perhaps an example is easier to understand, we have a boolean variable called status:

def doActionByStatus():
  if not status:
    # Perform tasks if status is false
    text = "The system is not functioning properly."
    return(text)

  # Perform tasks if status is true
  text = "All systems are performing well"
  return(text)

Don't worry about the function will proceed when status is false and the tasks inside are executed. After the function reaches the first return() within if statement, it will exit. Else, the function will just do the tasks after if statement.

Conclusion

Alright, hope this article can help junior developers and freshgrads in their careers. There are a lot of writing practices that helps writing better, cleaner and more maintainable code.

If you can do these as a habit, when your next juniors come and work with you, they will thank you.

Flasker - Definitely Minimal Flask Boilerplate

Brian Ting — Mon, 30 Nov 2020 03:05:46 +0000

I created a minimal Flask boilerplate for developers who want to create a Flask-based web apps from scratch, quickly.

The boilerplate repo: https://github.com/tyu1996/flasker

It is minimal enough that devs are given flexibility and no need to spend too much time trying to understand the codebase. With some experience with Flask, you can start to develop right away.

This boilerplate has complete set of what minimal web app should have: webpages, routes, forms, and models. It comes with a sample template so you can check around the web app first by running the run.sh.

Automate Stuffs with GitHub Actions on Publishing AppImage

Brian Ting — Fri, 17 Apr 2020 07:48:41 +0000

I was using travis-ci for buidling and releasing AppImage, until I discovered GitHub Actions recent these days. Since the repos are hosted on GitHub, why not take a try on its own CI/CD for my simple jobs?

This article discusses about using GitHub Actions for automating the AppImage build process and release it for users.

What is AppImage you ask, here provides great explanation and samples.

GitHub Actions

FYI, CI/CD stands for "Continuous Integration and Continuous Delivery". In short, CI/CD automates the building and delivering processes to make developers' life easier.

GitHub introduced its own CI/CD named GitHub Actions. By using GitHub Actions, just push your code to the repo, it builds, test, and upload to release automatically for you. But first, a defined workflow is required.

Actions in action

In Actions, there is a concept of workflows and actions. You can say a workflow contains many actions, and each action performs different set of tasks to achieve a particular job. A GitHub repo will have a workflow, but has different actions, which the tasks are written in yaml files.

Take an example, I have a repo contains AppImage building configurations for Opera. A build.sh in root directory tells a Linux machine to build an AppImage package from deb file.

In the repo, I created a directory .github/workflows. Actions will look for this directory, and take actions from all yaml files within. In this case, one yaml file is enough.

I recommend people to take a look on the documentation to familiarise with the syntaxes. Inside the workflows directory, a build.yml file was created. Now, let's go through the flow one-by-one.

.github/workflows/build.yml

name: AppImage Build
on: push
jobs: ...

These are the most basic syntaxes for Actions to perform CI/CD. The syntax is very straightforward: define the action name, when the action starts, and the jobs will be carried out. In this case, the action will start while GitHub senses a push to the repo. Let's continue.

jobs: 

  # This workflow contains a single job called "build"
  build:
    runs-on: ubuntu-16.04

    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@master

    ...

Within jobs, first thing is to give a job named "build", and specify which operating system to do the job. GitHub offers two LTS versions of Ubuntu, Windows Server 2019 and macOS 10.15. The rest of the tasks will be performed under "steps". We have to clarify which branch in our repo is used for building process, the code above checks out the master branch. Let's continue.

    steps:
    ...

    # Runs a single command using the runners shell
    - name: Install required dependencies
      run: sudo apt-get install desktop-file-utils zsync

    # Runs a set of commands using the runners shell
    - name: Download building tools & executing AppImage build
      run: |
        wget -nv -c https://github.com/AppImage/pkg2appimage/releases/download/continuous/pkg2appimage-continuous-x86_64.AppImage
        wget -nv -c https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage
        ./build.sh

For each task, a "name" and either "uses" or "run" tags are required, and only can be used once. First task installs all required dependencies for building AppImage with single command; second task downloads and executes AppImage build, which GitHub allows multi-line commands by putting a pipe | after "run:"

At this moment, an AppImage has been built. So, the artifact(s) should be uploaded to Release page for users to download. Let's continue.

    steps:
    ...
    ...

    - name: Create Release
      uses: ncipollo/release-action@v1
      with:
        allowUpdates: True
        tag: continuous
        name: Continuous build
        prerelease: True
        artifacts: "out/*"
        token: ${{ secrets.GITHUB_TOKEN }}

Luckily, we have someone created a useful Action for handling the task. The Action helps create a release tag and upload the artifact(s). Specify the repo in "uses" tag, and feed in the parameters under "with" tag. More optional parameters is being explained in the repo, do take a look.

One thing to take note is the "allowUpdates" parameter. Some AppImage package contributors tend to upload the latest version under the pre-release tag, replacing the old version. In default, GitHub Actions will cry out loud for existing release tag and refuses to upload the artifact(s). Set "allowUpdates" to True to replace the old version in the same release tag.

Commit change and see

Now, try to commit this change and push to the repo. When GitHub senses the presence of .github/workflows directory in the repo, it will trigger the CI/CD.

Conclusion

That's it! My first transition from travis-ci to GitHub Actions was a success. In my opinion, GitHub Actions is a more convenient choice for building and publishing AppImage packages on my repos.

Through this article, I hope more AppImage package contributors can take advantages of CI/CD to publish their packages faster and easily. And for those who are interested on building AppImage packages, you are always welcomed to the community ;)

[Question] UI/UX learning materials for developers

Brian Ting — Sat, 20 Oct 2018 09:33:54 +0000

I am experienced in Python programming, and recently I learnt a bit of Angular(TS) and Tkinter.

I think I had enough time to do purely coding. I wish to learn how to think and make a program that gives good user experience. Do you guys have any recommendation like books, or online learning materials about UI/UX?

Edit: Seems I misunderstood the co-existence of UI and UX (strictly said they both cannot be considered as a same thing). Should be clear is that I wanted to learn UI stuffs.

How I get to my goals

Brian Ting — Thu, 28 Jun 2018 14:28:52 +0000

Hello to this brilliant community. This is my first post and I am not an English speaker, sorry for any grammatical problems.

I would like to share how I begin my journey to computer science.

Programming owned my heart

I was drawn to programming stuffs when I was around 14-15 years old. I don't remember what actually drove me to get into software development that time, but every time I think about softwares, I believe that I could also make one.

My first programming language was C, which learned from a very old textbook I borrowed from my middle school teacher. When I compiled my very first program Hello World, I thought I was like a god. I can create anything that works.

Programming owned my heart. I was a lazy student in class that I can almost failed on any subjects, but my teacher told me that I should get a good grade on science-stream subjects especially maths so I can enter Computer Science in university. That was the first time I truly try to change myself, I studied hard on maths. The only goal was: I want to study Computer Science.

As a university student now

I achieved my first goal and is a Computer Science student. I found I have limited amount of time everyday besides study/homework time. I asked myself: How can I keep pursuing knowledge aside of school things?

I learnt to manage my time, set my daily/weekly tasks and control my time spending. This does hugely improve the efficiency of doing anything so that I won't be able to waste too much time on something that won't do any benefits.

Studying in university has widened my knowledge view that we are not only to code, but learnt there is many things to consider and to drive you to code. Studying is not for grades, but for how you smart use the knowledge to solve current issues. This is the most valuable thing you can get in university.

If you are also a student like me, I encourage you to treasure your every second on pursuing what you like. What got you here, where do you want to go, this would be your life direction. Grasp it, it is your golden age in your lifetime.

What is my current plan?

I am currently interested on Deep Neural Network and Stochastic Computing, and just started to study them. Hope one day I can use them for something useful.

DEV Community: Brian Ting

Software Engineering in 2026: A View From the Server Room

Where I Agree: AI Has Changed the Game

The Part Nobody Talks About: Operating Systems

What Production Experience Teaches You

Why Backend Work Feels Different

The Skills That Matter More Now

The "Build vs. Operate" Gap

Looking Forward

Flutter State Management Made Simple: Mastering Riverpod in Practice (Part 2)

Implementation Deep Dive

1. Basic Implementation

1. StateProvider: Ideal for ephemeral state (e.g., counters, switches).

2. StateNotifierProvider: Manages complex business logic with immutable state.

3. FutureProvider: Handles async operations like API calls.

2. Advanced Scenarios

3. Common Pitfalls & Best Practices

4. Testing

Wrapping Up

Flutter State Management Made Simple: Why Riverpod Should Be Your Next Choice (Part 1)

Understanding Riverpod and Its Value

1. What is Riverpod? The Swiss Army Knife of Flutter State Management

2. Why Riverpod?

3. Riverpod vs. Alternatives: A Pragmatic Choice

4. When NOT to Use Riverpod?

Wrapping-up

Deploying Flutter Web App on Live Server

Build Your App

Install Necessary Software

[Optional] Serve Your Web App using Express

Configure Firewall and Port Forwarding

Open Up a Port

Port Forwarding

[Optional] Configure Backend for CORS

Thanks for Reading ;)

Communicate with Microsoft SQL Server that works on Flutter app compiled for multiple platforms

Background

What To Do?

Middleware -- FastAPI + SQLAlchemy

Starting The Project

Queries

Paths

On Flutter's Side

Start the Server

The End

Some Code Refactor Tips for Junior Developers

Tip 1: Functions

Tip 2: Source files based on purpose

Tip 3: Negation IF

Conclusion

Flasker - Definitely Minimal Flask Boilerplate

Automate Stuffs with GitHub Actions on Publishing AppImage

GitHub Actions

Actions in action

Commit change and see

Conclusion

[Question] UI/UX learning materials for developers

How I get to my goals

Programming owned my heart

As a university student now

What is my current plan?

1. `StateProvider`: Ideal for ephemeral state (e.g., counters, switches).

2. `StateNotifierProvider`: Manages complex business logic with immutable state.

3. `FutureProvider`: Handles async operations like API calls.

**4. When NOT to Use Riverpod?**