REST vs gRPC for a public API in 2026

2026-06-15T15:02:00+03:00

The problem</h1>
I am adding a server to my Flutter</a> app Doshboard</a> (intentionally overengineered for learning - don't do this in your pet projects). Internally the microservices already talk gRPC</a>, but the public API conventionally uses REST, so I put a REST - gRPC transcoder in front of them.
Do I need that transcoder though? My users wouldn't mind lower data usage and better streaming, and I wouldn't mind deleting a translation layer - especially that Dart is officially supported</a>. So the question for this post: can I drop the transcoder and run gRPC end-to-end in 2026, or are the old problems still there?

Goals</h1>
What do I want from the client-server API:

Cheap on the wire - less data and CPU, which on mobile means cellular data and battery.</li>
A strict shared contract - one source of truth both ends are generated from, and tests are ran against.</li>
Native bidirectional streaming - real-time sync without bolting on a second protocol.</li>
Works on every client - mobile, desktop, and web.</li>
Minimal extra infra - no transcoder, no separate streaming server/load balancer.</li> </ul> The options</h1>
The current set of available options seems to be:

Translate to REST - gRPC-gateway</a> or Envoy</a> generate a REST API from the `.proto</code> specification. The conventional default. Both actively maintained.</li>`
`gRPC</a> + gRPC-Web</a> - gRPC on the wire: native HTTP/2 + protobuf for mobile/desktop, gRPC-Web (re-encoded, via a proxy such as Envoy</a>) for browsers. Core gRPC is active; gRPC-Web is in maintenance mode</a>.</li>`
Connect</a> - mostly gRPC's efficiency (binary protobuf over HTTP/2) but reshaped to talk HTTP with some quality a better observability. Native clients reach gRPC directly; web still needs a Connect - gRPC bridge (Envoy or a Connect edge), transcoding is lighter than from JSON though. Actively maintained.</li> </ul> Why even consider gRPC</h1> gRPC being the more capable protocol isn't really controversial: Performance: less data on the wire, fewer CPU cycles serializing, one reused connection - less latency and battery drain.</li> Contract-first: the .proto</code> always comes first by design. REST's OpenAPI codegen isn't that great, so you end up implementing API first and documenting it later which is never done. With gRPC spec tests and server mocks are free.</li> Streaming: native, bidirectional, same stack and types. REST streams one way at best (chunked/SSE); bidirectional needs a second protocol (WebSocket), often its own server and load balancer.</li> Flow control: cancellation, deadlines, backpressure built in.</li> </ul> So is it realistic to gain all these benefits in a multiplatform app in 2026? Option 1: Translate to REST</h1> The conventional default, and what my transcoder does today. It's nearly free if Envoy is already your edge - the gRPC-JSON transcoder</a> is just a filter. gRPC-gateway</a> does the same as a standalone proxy behind any ingress, at the cost of one more service to run. The control group we compare to. Both gRPC-gateway</a> and Envoy</a> are actively maintained. Option 2: gRPC + gRPC-Web</h1> Here you can get all the benefits, but it very much depends on the client platform. Native (mobile, desktop)</h2> Full gRPC gets you all the benefits mentioned above. If you don't have web clients - the choice is clear, or is it? Their client lives in uncontrolled environment, meaning things like CGNAT, TLS inspection proxies, and corporate DPI firewalls. CGNAT seems not to be an issue, except for dropping a connection from time to time, especially if it sits idle, but first of all this is not an unrecoverable error, and secondly, and most importantly, this issue affects any kind of streaming, including the ones REST API would rely on, namely web-sockets and SSEs. Majority of firewalls and proxies also shouldn't be an issue, since traffic is HTTP/2 encrypted with TLS - it doesn't look too different from a web socket connection. What is an issue is TLS terminating proxies</a>, if they downgrade the 'internal' leg of their connection to HTTP/1.1. Though I am yet to encounter one in the wild, and don't expect my users to be the ones who would. Web</h2> Browsers can't speak native gRPC simply because they don't expose the API specific to any given HTTP version, instead they want web developers not to care what generation of HTTP is used, so it is abstracted out. This is great for the REST, but gRPC needs control over individual HTTP/2 frames, which makes it not a viable option for browser usage as is. Couple of years ago Google was pushing gRPC-web as a way of covering the gap. The idea behind it was that gRPC is carried, with minimal changes, over a plain HTTP request, with a proxy such as Envoy translating it back to gRPC. You can see this even in Dart's gRPC package structure: the grpc</code> package</a> doesn't list web as a supported platform, yet ships a separate grpc_web.dart</code> library just for the browser. That is why. It has a bunch of limitations, such as limited streaming capabilities, no flow control, limited cancellation, CORS preflight penalties, but what is more important is that it is now in maintenance mode</a>. Because it was built on two of Google's own libraries - that have since been archived, maintaining the protocol became too cumbersome. The current official recommendation is to use gRPC-Gateway, which brings us back to option 1</a>. Other downsides</h2> Debugging & tooling: while tools like Postman</a> or Bruno</a> do support gRPC, and there is grpcurl</a> to replace curl for the CLI interactions - you still lose ability to glance at traffic in your dev tools or request logs, which does reduce the debuggability of the set up.</li> Caching & CDNs: since every call is a POST on a long-lived connection - cache goes out of the window basically, so for a read heavy application - you may even lose in terms of speed.</li> Load balancing: a non-issue in practice - a public REST API already sits behind an L7 reverse proxy, the only extra requirement is that it be gRPC-aware, which all the modern ones are.</li> HTTP semantics: your monitoring tool should be aware of, for example, gRPC error codes. You can't anymore rely on error detection based on HTTP status codes.</li> </ul> Core gRPC is actively maintained; gRPC-Web is in maintenance mode</a>. Option 3: Connect</h1> Connect</a> is an attempt to fix most of the issues gRPC presents while keeping the efficiency. It's a new protocol that is designed to be fully compatible with generic HTTP, which resolves a lot of the downsides gRPC's HTTP/2 reliance brings. Pros: Stub generation from .proto</code> specification</li> Binary protobuf payloads</li> Works over any version of HTTP, including 1.1, which makes it: Browser native</li> curl</code>-able</li> Cacheable for calls with no side effects, since they can use GET</li> Error detectable, since they now live in the HTTP response</li> Removes the need of interop layer on the client</li> </ul> </li> Important for my case it has official dart package</a></li> </ul> Cons: You still need a translation layer, though less intensive one compared to REST since it is just repackaging of a packet rather than full remarshalling</li> The protocol is much less adopted, so less tooling, less support</li> Streaming is still limited on web, mostly individual requests are used</li> </ul> Actively maintained by CNCF. Summary</h1> Capability</th> Translate to REST</th> gRPC + gRPC-Web</th> Connect</th></tr></thead> Web support</td> ✅</td> ✅ via proxy</td> ✅</td></tr> Low bandwidth (client)</td> ❌ JSON</td> ✅</td> ✅</td></tr> Bidir streaming</td> ❌</td> ✅ native / ❌ web</td> ✅ native / ❌ web</td></tr> Caching / CDN</td> ✅</td> ❌</td> ✅</td></tr> Tooling / debugging</td> ✅</td> ⚠️ binary</td> ⚠️ binary / ✅ JSON</td></tr> Monitoring on HTTP status</td> ✅</td> ❌</td> ✅</td></tr> Network robustness</td> ✅</td> ⚠️ native needs e2e HTTP/2</td> ✅</td></tr> Strict client contract</td> ⚠️ OpenAPI</td> ✅ proto</td> ✅ proto</td></tr> Dart support</td> ✅</td> ✅</td> ✅</td></tr> Edge translation</td> heavy transcoder</td> proxy (web)</td> light bridge (web)</td></tr> Maintenance</td> ✅</td> ⚠️ gRPC-Web in maintenance</td> ✅</td></tr> Ecosystem / adoption</td> ✅ huge</td> ✅ mature</td> ⚠️ young</td></tr> </tbody></table> The conclusion</h1> So is gRPC viable in 2026? I'd say no. Large projects, the ones that actually may benefit from such a decision, are very dependent on caching, on having clear visibility into the data, and on supporting as many clients as possible - which basically rules out gRPC for them, in both web and non-web forms. The fact that gRPC-Web is in maintenance mode makes this ruling even simpler. Connect, on the other hand, is tempting. I came into writing this post thinking I'd choose it for my project, for research purposes if nothing else, but looking at the picture we have here - it's still a bunch of complexity for a fairly modest gain. So I'd say it still shouldn't be a choice, unless both performance and robustness are of the highest priority. To conclude: gRPC to REST conversion still should be the default. If you need to keep the amount of data between client and server to a minimum, or you need the most performant streaming you can get, and reliability is not an issue - gRPC is the choice. If you need it to be reliable too, though - go with Connect. I will continue with the REST API for my project. Beyond the Empty Build: Evolving Riverpod Architecture 2026-01-17T15:47:00+07:00 After developing for some time with BLoC</a>, I finally made the switch to Riverpod</a>. The benefits looked really clear as I saw Riverpod as an evolution of BLoC that goes beyond the abstractions of business logic and actually handles orchestration of the logic blocks. However, with this orchestration comes complexity, and not complexity of riverpod itself, but from the fact that you now can do the same thing in multiple ways, and it isn't always obvious which path is the "right" one. The Code with Andrea</a> blog was a godsend during my initial search for a solid architecture. The system he came up with</a> covers everything, but some things didn't quite sit right with me. One such thing that immediately felt off was the empty build</code> method in notifiers acting as view controllers</a>. The "Empty Build" Pattern</h3> It may actually be the best way of handling a side effect's (like signing in or submitting a form) state as opposed to the view state itself in the Riverpod 2.x, using an AsyncNotifier<void></code>. It looks like this: @riverpod class SignInScreenController extends _$SignInScreenController { @override FutureOr<void> build() { // no-op: This controller provides no initial data. } Future<void> signInAnonymously() async { state = const AsyncLoading(); state = await AsyncValue.guard(() => ref.read(authRepositoryProvider).signInAnonymously()); } }</code></pre> I think that at the time, this was a perfectly valid way to handle UI state. Thanks to Riverpod’s use of result wrapper to indicate if a side effect is ongoing or failed. But when migrating my logic from BLoCs I couldn't get rid of feeling that the state has to be managed centrally without splitting the responsibility. The Problem: Fragmented Responsibility</h3> The empty build</code> method essentially exports the state of the notifier back into the UI. Because the controller is "stateless" (returning void</code>), it doesn't actually hold the data the view needs. It only holds the status of the last action. This forces the UI to manage a split personality: It watches the Controller to see if a button should show a spinner.</li> It watches a different Provider elsewhere to get the actual data.</li> </ol> Instead of gracefully handling state transitions in a single place, the controller triggers an effect, updates a separate provider, and leaves the UI to interpret the result. This makes the UI a middleman for logic that the Notifier is perfectly capable of handling itself. A Code Comparison: Split vs. Concentrated</h3> To see why this matters, let’s look at how we update a user's profile. 1. The Split State (Empty Build)</h4> Here, the logic is fragmented. You have to manually keep two providers in sync. FutureOr<void> build() {}</code></pre>graph TD subgraph UI ["Widget Tree"] W[View / Widget] end subgraph Logic ["Riverpod Providers"] DP[Data Provider] Ctrl[Controller] end DB[(Database)] W -->|1. Call Action| Ctrl Ctrl -->|2. State = Loading| W Ctrl -->|3. Update DB| DB DB -.->|4. Emit Event| DP DP -->|5. Trigger Rebuild| W DP -.->|5. Trigger Rebuild| Ctrl style Ctrl fill:#f96,stroke:#333 style DP fill:#bbf,stroke:#333</code></pre>2. The Concentrated State (The BLoC-like Way)</h4> By returning the actual data in the build</code> method, the Notifier becomes the single source of truth. FutureOr<User?> build() => userProvider.future;</code></pre>graph TD subgraph UI ["Widget Tree"] W[View / Widget] end subgraph Logic ["Single Source of Truth"] N[User Notifier] end DB[(Database)] W -->|1. Call Action| N N -->|2. State = Loading| W N -->|3. Update DB| DB DB -->|4. Return Result| N N -->|5. State = Success + New Data| W style N fill:#dfd,stroke:#333</code></pre>The Better Solution: Riverpod 3 Mutations</h3> While the concentrated approach is cleaner, it has a downside: if the state is AsyncLoading</code>, the entire UI usually replaces the data with a spinner. What if you want to keep showing the old data while the "Save" button spins? This is where Remi, author of Riverpod</a> got us covered with Mutations</a> in version 3 solve this by separating the Application State (data) from the Transaction State (the side effect). Instead of a "Void Controller," you define a mutation: // A standalone mutation to track the "Save" action final updateNameMutation = Mutation<void>(); // UI Usage: onPressed: () { updateNameMutation.run(ref, (tsx) => ref.read(userNotifierProvider.notifier).updateName(name)); } // Watch 'updateNameMutation' for the button spinner, // while 'userNotifierProvider' continues to show the user data.</code></pre>Conclusion</h3> The "Empty Build" method was a necessary workaround in Riverpod 2.x for tracking side effects without a native tool. It was a bridge that helped us move away from manual setState</code> logic in our widgets. However, with the arrival of Riverpod 3, we can return to a more robust architecture. By using Mutations for side effects and keeping our Notifiers focused on holding data, we stop exporting state responsibility to the view. We can build upon the foundations laid by developers like Andrea while utilizing these new developments to keep our controllers meaningful and our UI predictable. Should dart generated files be commited into VCS 2026-01-17T14:57:00+07:00 So you’ve installed Riverpod</a>, Freezed</a>, or Drift</a>, ran the code generation for the first time, and noticed a bunch of new files with .g.dart</code> or .freezed.dart</code> appearing. Now you’re wondering: Should I commit these files to version control? Unfortunately, there is no "one size fits all" answer. The short version is: If you aren't sure, you should commit them. However, there are specific circumstances where you might choose not to. Why Dart is Different</h4> Unlike some languages that generate hidden bytecode or binary files (which should always be ignored), Dart</a> code generators produce actual .dart</code> source code that your application relies on to compile. For your app to function, these files must exist. If you choose not to commit them, either your CI/CD pipeline or every developer who pulls your code will have to generate them manually. The Case for Committing (The Default Path)</h4> If you are building a Library, you must include the generated code; otherwise, users cannot use your package. For Applications, committing is generally preferred for several reasons: Reliability: It prevents "bugs" caused by version mismatches. If the build machine has a different version of Flutter</a> or build_runner</code> than your local machine, the generated code might differ, leading to unexpected behavior.</li> Speed: Generating code makes pipelines slower and more expensive. Committing the files allows your CI/CD to start testing and building immediately.</li> Environment Consistency: Some packages, like Envied</a>, generate code based on environment variables. Committing these ensures that the code you tested is exactly what gets deployed.</li> </ol> The Case for Ignoring (The Exception)</h4> There are times when you may want to exclude these files from Git or force the pipeline to regenerate them: Security: If you use packages like Envied to inject production credentials via environment variables during the build process, you definitely want to regenerate that code in your secure pipeline rather than storing it in Git.</li> Repo Health: Generated files can "bloat" your VCS</a> history.</li> Merge Conflicts: If two developers modify the same model, the generated files will often result in complex merge conflicts that cannot be resolved manually.</li> PR Noise: Generated code adds thousands of lines to Pull Requests, making it harder for reviewers to focus on the logic that actually matters.</li> </ul> Conclusion</h4> As a general rule, commit your generated code unless you specifically need your pipeline to build a different version of the code (like environment-specific secrets) than what the developers use locally. If the "PR noise" bothers you, look into using a .gitattributes</code> file to mark generated files as linguist-generated, which collapses them automatically on platforms like GitHub. Hiding generated flutter files in Android Studio 2025-10-20T10:00:00+07:00 Say you are following Flutter</a> best practices using immutable models, and historically the best way of doing it have been the freezed</a> package. If you do - you are likely annoyed with all the files generated by it where you end up with 3 files instead of 1. Excluding these files from IDE</a> altogether is not practical since you may want to pick into the generated code to see what it actually looks like, especially in case of providers</a>. So is there a way to make these files less annoying when you don't need them? Yes! You can hide them from the project file tree while keeping them accessible when needed, it looks like so: It is very easy to enable this. Go to Project settings -> Appearance -> File nesting And add file extensions of generated files. .freezed.dart</code> and .g.dart</code> in our case. That's it. Simple. N+1 query problem in Django ORM 2025-08-16T15:23:51+07:00 The N+1 Query Problem: A Django Developer's Nightmare (And How to Wake Up)</h2> Picture this: Your Django application has been humming along beautifully for months. Users are happy, servers are stable, and you're feeling pretty good about your architectural choices. Then you casually open Sentry</a> for your morning dose of masochism, and BAM—a new issue appears like an unwelcome party crasher: "N+1 Queries Detected." The timestamp? Right when you deployed that shiny new "user groups" feature you spent weeks perfecting. You click through to the session replay, watch in horror as your once-zippy request crawls along like it's stuck in digital molasses, and think: "What fresh hell is this?" Welcome to the N+1 query problem—Django's favorite way of reminding developers that laziness isn't always a virtue. The Problem (Or: How Your ORM Became a Database Interrogator)</h3> The N+1 query problem is like that friend who asks "just one more question" after every answer you give. Here's what happens: your application loads a list of N items, then proceeds to make 1 additional query for each item in that list. Instead of the single, efficient database conversation you expected, you end up with N+1 separate database round trips. It's like going to the grocery store and making a separate trip for each item on your list. Technically it works, but your database administrator is definitely judging you. Why Does This Happen? (The Perfect Storm)</h3> The N+1 problem requires just three ingredients to create the perfect storm: A relational database (check—you're using PostgreSQL/MySQL/SQLite)</li> An ORM with lazy loading (double check—Django ORM loves being lazy)</li> A list of items to iterate over (triple check—what's an app without lists?)</li> </ol> Since Django ORM is lazy by default (and who can blame it?), encountering this problem isn't a matter of "if" but "when." It's practically a rite of passage for Django developers. A Classic Example (Starring Books and Authors)</h3> Let's say you have two models that would make any literature professor proud: class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) author = models.ForeignKey(Author, on_delete=models.CASCADE)</code></pre> You want to display a simple list of books with their authors. Piece of cake, right? books = Book.objects.all() for book in books: print(book.title, book.author.name)</code></pre> Congratulations! You've just created a database query monster. Each time you access book.author.name</code>, Django's lazy ORM thinks, "Oh, you need that author? Let me make a quick database trip for you." Multiply that by however many books you have, and you've got yourself a performance nightmare. If you have 100 books, you're making 101 queries (1 for the books + 100 for the authors). Your database is working overtime while your users are wondering if their internet connection died. The Solution (Or: How to Make Your ORM Stop Being Lazy)</h3> The fix is beautifully simple and follows the "work smarter, not harder" principle: if you know you'll need related data, fetch it all upfront instead of playing database ping-pong. Django makes this almost embarrassingly easy with select_related</code>: books = Book.objects.select_related('author').all() for book in books: print(book.title, book.author.name)</code></pre> That's it. One line change, and you've gone from 101 queries to exactly 1. Your database can finally take a breath, your users get their pages instantly, and you get to keep your job. The Real Challenge (Detection and Prevention)</h3> Here's the catch: spotting N+1 queries before they hit production is trickier than solving them. You need a decent amount of test data and proper monitoring to catch these performance gremlins. In development with your 5-record test database, everything feels lightning fast. The sneaky part is that relationship access might happen far from where you created the queryset—like in a template that's three layers deep in your rendering stack. By the time you realize what's happening, your users are already experiencing the slowdown. Your Monitoring Arsenal</h3> Modern APM systems like New Relic</a> and Sentry</a> have gotten pretty good at detecting N+1 patterns automatically. However, they typically rely on thresholds (number of queries, execution time) to flag issues, which means they'll only alert you after the problem has already affected your users. Pro tip: Adjust your APM sensitivity settings to catch these issues earlier. Your future self (and your users) will thank you. The Bottom Line</h3> The N+1 query problem is like that recurring villain in superhero movies—it'll keep showing up until you learn to defeat it properly. The good news? Once you understand the pattern and Django's solutions like select_related</code> and prefetch_related</code>, you'll start spotting potential issues during code reviews and catch them before they escape into the wild. Remember: in the world of database queries, being lazy upfront often means working harder later. Sometimes the best performance optimization is simply asking for what you need, when you need it, all at once. Breaking Django ORM migrations 2024-03-28T14:13:00-07:00 Backward incompatible migrations</h2> Some migrations may be backward incompatible and will break production for a shot period of time between the migration application and pod rotation. This also will be a problem for a blue/green deployment if you to decide to implement it. To avoid this kind of downtime migration should be done in 2 steps. Caution</h2> Use this method only for the listed below operations. This method is dangerous. It can dissync the state of the app from DB. Never use self written SQL. Always copy it from the sqlmigrate command.</li> This type of migration is hard to revert for obvious reasons, so be extra careful doing it.</li> Doing this operation without using SeparateDatabaseAndState</code> will result into a downtime. Workers will refuse to start if change is made to the model, but not applied to the django internal state.</li> </ul> List of breaking migration operations</h3> RemoveField</code></li> DeleteModel</code></li> AddField</code> when the field is not nullable (there is no null=True</code> in the field declaration)</li> </ul> Solution</h3> Create 2 PR's and merge them into 2 separate releases: Usages removal PR</h4> Remove all the usages of the field from the code</li> Remove the field from the model</li> Autogenerate a migration (./manage.py makemigrations your_app</code>)</li> Retrieve the sql of the migration (we'll need it later) (./manage.py sqlmigrate your_app 0002_auto_20240328_1527</code>)</li> Move the breaking operations to SeparateDatabaseAndState</code>s state_operations</code> (example below).</li> </ol> Database changes PR</h4> Create empty migration (./manage.py makemigrations your_app --empty</code>)</li> Add SeparateDatabaseAndState</code> again</li> Put the SQL extracted in step 4 of previous PR creation into database_operations</code>. Without comments and transaction parts.</li> </ol> Example</h4> Autogenerated migration:</h5> from django.db import migrations class Migration(migrations.Migration): dependencies = [ ('team_management', '0001_auto_20240319_1146'), ] operations = [ migrations.RemoveField( model_name='organization', name='session_expiration_time', ), ]</code></pre>PR 1</h5> from django.db import migrations class Migration(migrations.Migration): dependencies = [ ('team_management', '00001_auto_20240319_1146'), ] operations = [ migrations.SeparateDatabaseAndState( state_operations=[ migrations.RemoveField( model_name='organization', name='session_expiration_time', ), ] ), ]</code></pre>PR 2</h5> from django.db import migrations class Migration(migrations.Migration): dependencies = [ ('team_management', '0002_auto_20240328_1527'), ] operations = [ migrations.SeparateDatabaseAndState( database_operations=[ migrations.RunSQL( sql=( 'ALTER TABLE "team_management_organization" DROP COLUMN "session_expiration_time" CASCADE;' ), ), ] ), ]</code></pre> Flutter tests in gitlab pipelines 2024-02-25T13:23:17+10:00 Lets save you and future me 5 minutes of precious time as of how to parse the dart tests and coverage results in gitlab pipeline. tl;dr</h2> In your .gitlab-ci.yml</code> image: instrumentisto/flutter:latest stages: - test test: stage: test before_script: - export PATH="$PATH":"$HOME/.pub-cache/bin" - flutter pub get - flutter clean - flutter pub global activate junitreport - flutter pub global activate cobertura script: - flutter test --coverage --machine | tojunit -o report.xml - genhtml coverage/lcov.info --output=coverage - cobertura convert coverage: '/^\slines\.+: (\d+\.\d+)% ./' artifacts: when: always paths: - report.xml - coverage/ reports: junit: - report.xml coverage_report: coverage_format: cobertura path: coverage/cobertura.xml expire_in: 1 week</code></pre>A bit of explanation</h2> - export PATH="$PATH":"$HOME/.pub-cache/bin"</code> - Is needed to make packages we install globally callable by the script - flutter pub get</code> - You likely need your stuff to run tests don't you? - flutter pub global activate junitreport</code> - A package</a> that converts test results output of dart to a junit format which gitlab understands - flutter pub global activate cobertura</code> - A package</a> that converts coverage report from lcov</code> format used by dart into cobertura.xml</code> that gitlab understands. | tojunit -o report.xml</code> - tests conversion, the resulting path will be %project_root%/report.xml</code>, feel free to change to your liking, but you'll also need to adjust the artifacts</code> section of the step accordingly. - genhtml coverage/lcov.info --output=coverage</code> - Conversion dart coverage result into an xml report. By default, dart test suit outputs it to the coverage/lcov.info</code>. This command converts lcov.info</code> into xml parsable by the cobertura. You'll need lcov</a> OS package to be installed for this to work, I use image instrumentisto/flutter</a> with it being included. cobertura convert</code> - Gives us a final result. Cobertura package will generate a file called cobertura.xml</code> in a directory you tell it, in this case its %project_root/coverage/</code>. coverage: '/^\slines\.+: (\d+\.\d+)% ./'</code> - Regexp to parse the coverage percentage which will be shown as your pipeline result and in you repo stats. (Se pictures below, just don't look at the number. Really, don't🫠) In the artifacts</code> part we are telling gitlab where to find the reports and what each of them mean. Adjust the paths here if you changed them previously. As a result you can see individual test results, the execution time in the piepline, and a coverage in the MR diff and the pipeline. OpenVPN server on Truenas Scale 2022-08-06T00:30:17+03:00 The setup</h2> So you have a truenas scale</a> server, which holds all your most precious data</a>. And chances are this is a machine you want to be able to access from anywhere because of this. Maybe even you want to actually utilize the sharing capabilities of your NAS, like Samba to use your data. Good use of resources would be to turn you NAS into a VPN server. This is done really easily on Truenas scale specifically: basically one press of a button and you are done. So I assume you already have you OpenVpn server up and running and can connect to the Nas via it. In my case the 10.0.0.0\24 network is a VPN and the 192.168.1.0\24 is a remote LAN. In your case ranges can differ. The problem</h2> But what if you now want to be able to access any device in that network. Like if it's your home network, and you have a couple of useful devices there which you don't want or cant connect to the VPN individually. So our goal here is to be able to connect to 192.168.1.1 via VPN while only the 192.168.1.5 is connected to the VPN (a VPN server in our case) The solution</h2> In order to access the LAN of your Truenas Scale server you'll need to enable an ip forwarding. Between the interfaces on the NAS. This will allow traffic to flow freely from the VPN network into LAN and back, giving you easy access to the resources in the LAN. All the actions we require need to be done from advanced system settings so navigate to System Settings</code> -> Advanced</code> Add a sysctl variable named net.ipv4.ip_forward</code> with value 1</code> and enabled checkbox ticked.</li> On a neighboring panel called 'Init/Shutdown Scripts' add following 3 Command</code>s with the names you will understand: Command: nft add table ip nat</code>, When: Post init</code></li> Command: nft 'add chain ip nat prerouting { type nat hook prerouting priority 0 ; }'</code>, When: Post init</code></li> Command: nft 'add chain ip nat postrouting { type nat hook postrouting priority 100 ; }'</code>, When: Post init</code></li> </ol> </li> We also need a 4-th Command</code>, but you need to know 3 values in order to form it correctly. The easiest way to do it is to navigate to System settings</code> -> Shell</code> and execute the ip address</code> command. you can find the necessary values by searching for IPs you recognize as the on from the LAN and the one from the VPN networks. The values you need are: Name of the openvpn network interface. Mine is openvpn-server</code></li> Name of the lan interface. Mine is enp2s0</code></li> The VPN subnet CIDR. Mine is 10.0.0.1/24</code></li> </ul> </li> Add the 4-th command replacing my values with yours. The Command will be nft 'add rule nat postrouting iifname openvpn-server oifname enp2s0 ip saddr 10.0.0.1/24 masquerade'</code>, and when the field is Post init</code></li> THe last and really optional step is to make your clients know how to route traffic to your server's LAN. In order to do that - navigate to the Network</code> -> Open VPN</code> -> Server</code> and add push "route 192.168.1.0 255.255.255.0"</code> to Addtional parameters</code> field. Replacing the ip with your LAN ip ofc. That's it 🎉. Now reboot your NAS. And go verify on the client if everything worked.</li> </ol> Verification</h2> Connect to the VPN from your client and try to ping or access in any other way the ip from your server's LAN (192.168.1.1 in my case). It works, yay! About 2022-06-22T00:00:00+00:00 Welcome to my little corner of the internet 👋 I'm Igor. By day I build backend services and distributed systems; the rest of the time I tinker with all sorts of other tech such as Flutter, SDR, self-host more than is reasonable, and work from wherever I happen to be. This site is where I write down the things I know I'll want to look up again later. I am open for work.</h2> View Resume 📝</a> igor@shtein:~</div> </div> </div> igor@shtein:~ $ whoami I build backend services and distributed systems — Python, Rust, and the infrastructure to run them in production. $ cat availability.txt Open to full-time roles remote or on-site in Israel. If you need a technical expertise in building a back-end system of any type, or a skilled developer - let's talk. $ mail -s "Hey 👋" igor@shtein.me</a> </div> </div>

Igor's corner

REST vs gRPC for a public API in 2026

Beyond the Empty Build: Evolving Riverpod Architecture

Should dart generated files be commited into VCS

Hiding generated flutter files in Android Studio

N+1 query problem in Django ORM

Breaking Django ORM migrations

Flutter tests in gitlab pipelines

tl;dr</h2> In your .gitlab-ci.yml</code></p>

A bit of explanation</h2> - export PATH="$PATH":"$HOME/.pub-cache/bin"</code> - Is needed to make packages we install globally callable by the script</strong></p> - flutter pub get</code> - You likely need your stuff to run tests don't you?</p>

OpenVPN server on Truenas Scale

Verification</h2> Connect to the VPN from your client and try to ping or access in any other way the ip from your server's LAN (192.168.1.1 in my case). It works, yay!</p>

About

Verification</h2>
Connect to the VPN from your client and try to ping or access in any other way the ip from your server's LAN (192.168.1.1 in my case). It works, yay!</p>