DEV Community: Snir David

How to become a data engineer? Complete learning path

Snir David — Sat, 17 Oct 2020 13:29:27 +0000

Becoming a data engineer is not an easy path.

There are so many different subjects to control, with knowledge dependency between them that is overwhelming for someone who isn't already proficient in the area.

When I got into the subject, I struggled with that too even though I'm a senior engineer in the Fullstack development area.

Where do I start? SQL is obvious. Then I need to know how to manage a data warehouse? How should the data look in there? OLAP schema design is a subject in and of itself?

That's why I create the site awesome data engineering - learning path to become a data engineer.

The resources index is open source and up for community contribution!

The site makes it easy to see the different subjects, the complete learning path, and then to filter by the type of resources you prefer on each subject.

Hope you'll find this project useful (:

Data warehouse schema design - dimensional modeling and star schema

Snir David — Tue, 25 Aug 2020 12:13:59 +0000

Original post for Data warehouse schema design - dimensional modeling and star schema in my blog

Introduction to data warehouse schema design: In this talk, I walk through the basics of dimensional design using the kimball group approach.

Amongst other things, I cover:

OLAP systems vs OLTP systems
Third normal form of operational DB
What is a dimension
What is a fact
Star schema
Dimension grain
Surrogate keys
Slowly changing dimensions

Pragmatic weekend project - apartments bot

Snir David — Thu, 04 Jun 2020 17:37:29 +0000

Originally posted in my blog at: https://snir.dev/blog/apartments-bot/

Starting and completing a weekend project, is often challenging. Feature creep, tech stack choices and unwaranted tech excelency (100% test coverage for a weekend project anyone?) are your enemies, making the project timeline go beyond one weekend, which in turn usually results in the project never being done.

After countless such projects, I got to a place where I can confidently estimate a small project, define its features and use tech as a tool to complete my project. Preventing some ideological concepts and unnecessary perfection from getting in my way.

I've built a small project this weekend that will help me find my next apartment. And it is a great case study to demonstrate all lessons learned.

The problem

I'm looking for a new apartment to rent. In my local market, most land lords only advertise in private facebook groups. Each group is dedicated to another city/area. Which for me resulted in 7 different groups to cover my search area.

Going through the ads in facebook groups is a mess:

You need to individually visit several group pages in every "scan".
Posts with recent comments are bumped up, making you go through posts you already saw.
There is no easy way to filter posts.
This is tiresome, which might lead to me missing great opportunities that are time constrained (as these are high demand locations).

The solution

Before we dive in, if you are interested in the end result, my code is freely available at Github: https://github.com/snird/apartments_bot

Manually scanning multiple facebook groups every few hours is a long error-prone process. My automated solution had these requirements:

Visit all groups manually and receive all ads.
Remember which ads it already sent me, and filter those out.
Filter ads by some text, in my case "3 rooms", to get only relevant ads.
Send it to me in a way easily shareable with my partner.

I wanted to solve each of these requirements in the most pragmatic way possible. My top priority was to make it work, and be done with it within the span of a weekend. In the rest of this article I will share with you my technical decisions, reflecting on why I made them.

Facebook groups scanning

My initial thought was to use the facebook API to retrieve the posts in an easy to consume way. Unfortunately, some of the groups I needed are defined as "secret" and you cannot get their posts using the API.

With API usage out of the question, I had to resort to web scraping. I have strong experience with nodejs so it was no brainer for me to go that route. For node ecosystem Puppeteer came up and I started using it.

Facebook authentication

Puppeteers default is a headless browser. Every run is a clean start with no prior state (cookies, sessions etc'). Which means that I would have to authenticate to facebook every time. Handling authentication seemed out of my scope, and it is a one-time thing: connect to facebook.

Puppeteer also allows for a full regular Chrome session, connected through the debug socket. This allowed me to open Chrome, connect to my facebook account manually and then let my script use this Chrome instance. Not everything has to be solved by programming. I have goals I want to keep - functionality and time constraints.

Interested in reading the rest of the article?
Its available in my blog: https://snir.dev/blog/apartments-bot/

The difference between mocks and stubs, explained with JS

Snir David — Thu, 22 Aug 2019 20:25:17 +0000

Stubs and Mocks are two foundational concepts in testing that are often misunderstood. So much so, that we have the famous Martin Fowler article on the subject, alongside numerous stackoverflow questions on the matter.
Martins article is a long read for the modern impatient reader, get somewhat sidetracked and doesn't have example in the current hype language, JS.
I'll try to be more concise in my explanations here.

I'll start with the headline definition:
Stubs and mocks are both dummy objects for testing, while stubs only implement a pre-programmed response, mocks also pre-program specific expectations.

To put it into a workflow:

Stubs

Setup - define the stub itself, what object in the program you are stubbing and how
Exercise - run the functionality you want to test
Verify - check the stub for values that ran through it, that they fit expectations
Teardown - if needed, clean up. e.g Time stubs are usually global, you need to yield control back

Mocks

Setup object - define the mock, what object you are mocking and how (similar to stubs)
Setup expectations - define what you expect will happen to this mock internally
Exercise - run the functionality you want to test
Verify mock - verify that the mock expectations are met. In some JS libraries this happens automatically without additional call, the mock expectations are verifying themselves and will throw if needed. (Used mostly when async testing).
Verify - verify any additional expectations for results on the mock
Teardown - if needed, clean up.

Mocks & Stubs in the JS community

Before we get into code, since my examples will be in JS, there is an important note to be said here.

One of the most successful testing libraries in the JS community is jest. But I will not use it for my examples, for the simple reason that jest is opinionated and does not implement mocks.
What they call a mock in the library, is actually a stub by definition. You cannot make expectations on the mock itself, rather just look at its behavior and call and make expectations on that.

I will demonstrate the concept using sinon.js that does implement the concepts of both mocks and stubs.

Stubs example

For our example, we will unit test an imaginary function for purchasing items in an eCommerce site. We will try to pay and get the payment status, and if we are successful we will send a mail.

const purchaseItemsFromCart(cartItems, user) => {
  let payStatus = user.paymentMethod(cartItems)
  if (payStatus === "success") {
    user.sendSuccessMail()
  } else {
    user.redirect("payment_error_page")
  }
}

}
"when purchase payed successfully user should receive a mail" : function() {
  // Setup
  let paymentStub = sinon.stub().returns("success")
  let mailStub = sinon.stub()
  let user = {
    paymentMethod: paymentStub,
    sendSuccessMail: mailStub
  }

  // Exercise
  purchaseItemsFromCart([], user)

  // Verify
  assert(mailStub.called)
}

Mocks example

Now lets do the same, using mocks.

"when purchase payed successfully user should receive a mail" : function() {
  // Setup objects
  let userMock = sinon.mock({
    paymentMethod: () => {},
    sendSuccessMail: () => {}
  })

  // Setup expectations
  userMock.expect(paymentMethod).returns("success")
  userMock.expect(sendSuccessMail).once()

  // Exercise
  purchaseItemsFromCart([], user)

  // Verify mocks
  userMock.verify()
}

Great. When should I use each?

Now this is the interesting question here.
And there is much debate - there is a reason the guys behind jest decided not to implement classic mock functionality.

Mocks can do whatever stubs can do, plus setting expectations directly on the objects they are faking.
This creates readability problems for large tests as well as tendency to start expecting and testing fake objects within the test that are not the sole purpose of the test, making it a white-box test that is too aware of internals.

That is even mentioned as a guideline in sinon documentation for when to use a mock:

Mocks should only be used for the method under test.
In every unit test, there should be one unit under test.

So to not overuse this functionality and create a confusing, and maybe mispurposed test, you should limit your mocks usage in tests to one object.

Or, you know, you could just use jest that took this decision away from you by not implementing these kind of mocks in the first place.

Breadth first traversal for binary trees in JS

Snir David — Mon, 19 Aug 2019 13:12:50 +0000

Breath first traversal of binary trees is a basic thing to do.
So why do I write this post?
Because there is a gap if you try to quickly look for implementation in google.

Most of the articles cover generic trees, not binary tress. Thus have no concept of "left" and "right" nodes, but just unordered children.
https://medium.com/@kenny.hom27/breadth-first-vs-depth-first-tree-traversal-in-javascript-48df2ebfc6d1
https://medium.com/@stephaniewo/understanding-breadth-first-tree-traversal-with-javascript-9b8fe670176d
https://gist.github.com/thinkphp/1440007

And this might confuse a beginner.
Others, like this great article at hackernoon do a perfect job explaining the concept, but not presenting the code for it.

gif by by Stephanie Wong

So, assuming you'll read the concept of how we use queues to do the breadth first traversal at this great article at hackernoon, here is a modern implementation, specific to binary trees with left and right nodes.
(And as in the gif above, it will always go from left to right)

class Tree {
  constructor(value, left, right) {
    this.value = value
    this.left = left
    this.right = right
  }
}

const breadthFirstTraversal = (tree, callback) => {
  if (tree == null) {
    return;
  }

  let queue = [tree]

  while (queue.length > 0) {
    let item = queue.shift()
    let value = item.value
    callback(value)

    if (item.left == null && item.right == null) {
      continue
    }
    if (item.left != null) {
      queue.push(item.left)
    }
    if (item.right != null) {
      queue.push(item.right)
    }
  }
}

t = new Tree(1,
      new Tree(2, null, null), new Tree(3,
        new Tree(4, null, null), null))

breadthFirstTraversal(t, console.log)
// Will print "1,2,3,4"

Recursion optimization in JS - where is it? PTC, TCO and FUD

Snir David — Sun, 18 Aug 2019 21:43:10 +0000

ES6 is old news by now. It's fully implemented across all modern browsers. Nothing to see here.
The compat-table of ES6 by kangax that we used to check to see progress should be all green by now, right?

Well, it's not.

The proper tails call section, (tail call optimization) is red.

Why? is it a feature that can't be implemented for JS?
Well, no. There is one browser that implemented this feature. Safari.

Then it is possible, and it is out for large audience in Safari. Why does chrome and firefox lagging behind?

The answer is complicated. And as it seems from my browsing in many many bug trackers comments for V8, Firefox JS engine, github issues, TC39 committee discussions and more - also very political and opinionated.

I'll try to give here a bit of background on the subject, that may hopefully leave you knowing more why is this so hard.

PTC? TCO?

PTC - proper tail call
TCO - tail code optimization
These 2 terms are not the same. And it is important to understand the difference between them for the discussion ahead.

Assumptions moving forward

I don't want to make this article a primer on recursions and call stacks.
I will assume you already know about that part. In case you don't, freecodecamp have a great article regarding this.

Proper Tail Call

I'll say before starting, proper tail call is what should have been implemented in ES6, and not tail code optimization (which we will talk about later).
It is in the ES6 Standard document and if you can't read the Formal definitions of it (don't worry, neither can I) you can just look at the introduction:

Goals for ECMAScript 2015 include providing better support for [...].
Some of its major enhancements include modules, class declarations, [..]
and proper tail calls.

Proper tail call is a technique where the program will not create additional stack frames for a recursion that fits the tail call definition.
This, and this only is the proper tail call value proposition.

So, instead of having a recursion with all its stack saved in memory, we will have just one level of stack saved, optimizing the recursion stack.

But how can it be? Tail recursion functions basically keep passing all the necessary data it needs down the recursion, so you don't have to rely on the stack.

The classic example here is the Fibbonaci function.

Consider this in the classic (head) recursion:

function factorial(n) {
  if (n === 0) {
    return 1
  }
  return n * factorial(n - 1)
}

It has to rely on the stack on each step, as each step have to be "processed up" to the n * factorial(n - 1).

Now consider this tail recursive version:

function factorial(n, acc = 1) {
  if (n === 0) {
    return acc
  }
  return factorial(n - 1, n * acc)
}

In this version, we have an accumulator as an argument. This keeps track of the total so far. Therefore, the stack here have no use, all the data is available all the way down the recursion call.

Great! Recursive programming that is sometimes easier to grasp than the iterative alternative without the call stack problem. They are basically equivalent!

Only, they are not. Not in the PTC case.
The problems with PTC are described beautifully on a recent proposal for TCO in Ecmascript.

Basically, this is what they are:

Performance issues. This only optimize the call stack, not the calls themselves.
Debugging. The call stack will be tempered with unnaturally, a thing that might make debugging much harder.

Yicks. No wonder people are so passionate about their positions on this regard.
Some say the debugging issues is a deal breaker, and the performance issues will kill profiling. Others disregard this as FUD, since Safari implemented PTC and hell is still closed.

You can find adults fight passionately for what they believe here:
https://github.com/tc39/proposal-ptc-syntax/issues/23
https://bugs.chromium.org/p/v8/issues/detail?id=4698

Tail Call Optimization

Tail call optimization to the rescue!
Well, not really but I wanted to be dramatic.

Tail code optimization is different by the fact that it does not simply eliminate the additional stack calls, it completely re-compiles the recursive function to be an iterative one.

Behind the scenes, tail code optimization takes a recursive function and generate an iterative function, using goto internally, and then runs it.

It does not limit the stack calls, because there are none once the function is actually not recursive behind the scenes.

This solves the performance issues perfectly.
Lua actually has this implemented long ago and it works perfectly. A recursive function is identical in performance to its equivalent iterative function.

Alright, so why not just implement TCO?

Well... There is much debate about that too.
There are people who want "implicit" TCO - that is, when it recognizes a fit function for tail optimization - just do it in place.

And there are people who want "explicit" TCO - do this only if it is the developer intent by purpose.

This is what the current proposal for Syntactic Tail Calls is all about.

It introduces new syntax and new keyword for tail calls optimizations, namely the continue keyword.

And, again, much controversy here too it seems.

Will we have to beg third-party library owners to re-write their code?
The new syntax required will basically kill the feature before anyone will use it.
etc' etc'.

So, that's the story of tail call optimization in JS as it stands right now.
I didn't go too deep on the details, ofcourse, but I feel like this should give you a basic understanding on why this subject is complicated and hard to get right.
And as always - thank you to all the guys working on this subject and the Ecmascript proposals. Your work and passion-full discussions ends up benefit us all.

Functors from first principle - explained with JS

Snir David — Sat, 17 Aug 2019 14:02:02 +0000

In this post, I will explain what functors are and why they are useful in a different way than I was taught.
When I tried to learn about the functors concept I usually got to one of those explanations:

It is something you can map over (But what exactly does map means?)
It's like lists that you can map over (So, is mapping just looping through elements?)

Those weren't very useful for me. And I ended up reading very very long explanations, and reading many lines of real world code to get all the gotchas and the real meaning.
I will try to spare you, by explaining as fast as possible the concepts.

I will start with the general concept and some demos in JavaScript to make is accessible as possible, but I will end up going to Haskell here as there are things only Haskell can do that are important for your understanding.

Lists are functors - as you can map over them

Let's start with an anecdotal example and expand from there.
Lists as you know them from many languages are functors, as you can map over them.

const myList = [1,2,3,4,5]
const addTwo = (num) => num + 2
myList.map(addTwo) // [3,4,5,6,7]

Map is applying a function to a structure

So what we saw above, is basic map function for a list where we apply the addTwo function to every item in the list.
But mapping a bit more generic definitions is:

Applying a function over *or* around some structure while keeping the structure intact.

In lists, the structure is the list itself. We apply a function, addTwo, that has no otherwise knowledge of the existence of lists, over every item in the structure, the list.

Got it. Mapping over structure. What are structures?

It is a bit hard to grasp the concept of structures as first, when you only have the list example.
But this is where the important generic concept of functors come in play.
Think of the "structure" at play as a box, holding some kind of value in it. When mapping, you apply a function to a potential value within that box, while leaving the box intact.

Keeping us in the realms of javascript, a non-perfect, but still good enough example will be promises.
Promises are boxes that hold potential values, which you can apply a function over without changing the promise box.

let promise1 = new Promise(function(resolve, reject) {
  setTimeout(function() {
    resolve('foo');
  }, 300);
});

// `then` is the equivalent of `map` in our example.
promise1.then(console.log);

console.log(promise1); // Will print out [object Promise]

What happened here?
We have a Promise object, which is a box holding in future evaluation of value.
The then method applies a function to the value within that structure of promise, while leaving the promise object itself intact.
The then method is equivalent to map in our world.

Ok. Got it. But that looks pretty thin, what more is it useful for?

I'm with you. You need more examples to explain the value in this abstraction before we move on.
This is where I need to get out of the classic JS realm a bit, but not too far.
Let's introduce the Maybe Monad. Don't worry, the monad part have nothing to do with our explanation. Just the maybe part.

Maybe monads are a method to handle values that may or may not exists in a safe manner. Instead of having null or undefined values, you'll have Maybe handle the Nothing case gracefully, leveraging the functors methodology.

Basically, Maybe is a box for values that are optional. Let's assume we have an implementation, this is how it might look:

let maybeName1 = Maybe("Snir")
let maybeName2 = Maybe(undefined)

console.log(maybeName1)
// [status: "Just", value: "Snir"]

console.log(maybeName2)
// [status: "Nothing"]

Now, this Maybe structure is a box, that implements a map function, to be a functor! Let's look at a potential map implementation:

// (This is not how `this` really works, assume `this` here is the
// currently referred Maybe object itself. Just for ease of read)
Maybe.map = (fun) => {
  if (this.status === "Nothing") {
    return;
  }
  return fun(this.value)
}

Thus, enabling us to code this:

let maybeName1 = Maybe("Snir")
let maybeName2 = Maybe(undefined)
let maybes = [maybeName1, maybeName2]

maybes.map((maybeObj) => {
  maybeObj.map((name) => console.log(`Hi ${name}!`)
}
// Will logs: "Hi Snir!"

As you can see, the Maybe is a box for holding a value safely, while we can apply function using map to these values (and not needing to worry about checking for "null" values, as the Maybe implementation takes care of that).

In functional programming, these boxes are all over the place. And, may I say, in languages like Haskell with evolved type system, they are even more elegant.

There is more! one last weird example - functions.

So we understood that structures are boxes. Lists are a box for many values, Maybes are a box for safe evaluation of optional values.
But functions are boxes too. Boxes for code execution data.
We can map functions over functions too!

This is where it gets a bit weird, but this is the most important example IMO as it expands your view of what "structures" are.

Sadly, this is also where we have to leave the natural realms of JavaScript, as JS does not hold functions as perfect boxes for implementing functors on them.

The important bit here is natural partial application for functions, which exists in Haskell, Scala and many other functional-natural languages.

In Haskell for example, every function get just one argument, always. So how do we pass more than one argument? well, Haskell just automatically apply the function it created from the first argument, to a function with the second argument.

This creates a world where partially applied (or curried in other name) functions are a first class feature of the language.

Take a look at that:

-- This function takes 2 arguments: name, and address
printPerson name address = putStrLn (name ++ address)

-- Let's apply it with 2 arguments to get a print:
printPerson "Snir" " Tel Aviv"
-- This will print "Snir Tel Aviv"

-- We can also just partially apply, and store in another name:
printShani = printPerson "Shani"
-- This will not print anything yet. It just returns a partially applied function

printShani " New York"
-- This will print "Shani New York"

There are javascript libraries to make this "more" natural, like Ramdajs and it's friends.
I will demonstrate from now on with an "Imaginary" JS that naturally supports this, just so you'll have an easier time following the syntax, alongside haskell, for those who feel comfortable with it.

Let's look at some imaginary map implementation for functions in JS:

// NOTE: this is in an imaginary JS where partial application is natural. // This will not work in real life, it just for understanding the concept.
// And as with the example before, this is not really how `this` works.
// Just assume it refers to the context function, for readability.
Function.map = (fun) => {
  this(fun)
}

Which will theoretically enable us to do:

let add10 = (n) => n + 10
let multiply2 = (n) => n * 2
let addThenMultiply = add10.map(multiply2)

addThenMultiply(1) // Will result in 22

And this is a functor too now.
A function is a structure storing computational information, and mapping over it is changing the stored value - aka the computational information, from just "add 10" to "add 10 then multiply by 2" while not changing the structure itself, which is being the concept of function.

If you got that, it's pretty safe to say you get the conceptual generic idea of functors.

For brevity, and correctness (not playing with imaginary JS) here is the same thing in haskell:

-- The (->) is what represents functions in haskell.
-- This is an instance implementation of Functors to (->) - functions.
-- We implement the `fmap` here, which is just the `map` function.
instance Functor ((->) r) where  
  fmap f g = (\x -> f (g x))

-- Intentionally avoid point-free style, for easier read.
add10 n = n+10
multiply2 n = n*2

addThenMultiply = add10 `fmap` multiply2
addThenMultiply 1

Formality! Let's define functors formally.

Few. You got so far.
Let's just wrap it up with the formal definition of Functors.

A functor must implement map function such that it takes a function from type a to type b, and a Functor with value of type a, and returns Functor with type b.

-- Formal haskell type definition
(a -> b) -> f a -> f b

What does it mean? let's start easy.
We have a list [1,2,3] and a function addOne = (n) => n + 1
Then the list is the Functor, which holds values of type Number. Th function, is a function from Number to Number. So we should result again in a functor (list) of the same type (number).
[1,2,3] -> [2,3,4]

Now say we have a function from Number to another type:
strNum => (n) => "num: " + n
Then, going through the rule, it will be a function, from Number to String transforming a Functor (list) of Number to Functor of String.
[1,2,3] -> ["num: 1", "num: 2", "num: 3"].

Rules

For functors to work as expected, in any generic usage of function, we need to keep 2 basic rules:

Functors must preserve identity morphisms This basically means, that if I pass a no-op function for map, the functor should remain intact. Basically, map shouldn't change anything by itself, without the function provided.

let noop = (n) => n
[1,2,3].map(noop)
// Must return `[1,2,3]` again.

Functors preserve composition of morphisms This means, that mapping with a composed function, should give the same result as mapping with the functions separated.

let addTwo = (n) => n + 2
let MultiplyTwo = (n) => n * 2
let addThenMultiply = (n) => MultiplyTwo(addTwo(n))

[1,2,3].map(addTwo).map(MultiplyTwo) // [6,8,10]

// Must be equivalent to the use of the composition morphism:
[1,2,3].map(addThenMultiply) // [6,8,10]

That's it!

P.S
There are much more to be said about functors, and more variants of functors to cover.
This should give you a good understanding of the concept, and an easy gateway to more advance topics.

Why B2B startups shouldn't use React (or any JS framework)

Snir David — Sat, 10 Aug 2019 17:00:25 +0000

Before we dive in to the reasoning behind this title, let's set up some base definitions for the discussion:

Startups - The startups I'm referring to are small startups. If you will, up to 8 persons in the tech team. My claims might be valid for bigger teams, or even big companies depending on their organizational structure. This will be better explained on the reasoning.

Startups kind - There are many kinds of startups, and my claim can't possibly be relevant to all of them. I think my claims are more relevant for the B2B startups that provide some dashboard to users, rather than B2C startups that might need to have higher priority on user experience that SPA methodology might provide.

JS frameworks - The important distinction here is for front-end frameworks that are fundamentally disconnected from the backend such that it requires providing the overhead of writing specific APIs to serve it. React, Vue, Angular and others are complying with this definition.

With those definitions out of the way, we have a common language to talk about my claims.

To be honest, I'm not having any "revolutionary" idea here. The basic principles against using an JS frameworks for front-end have been laid out by many others before me, just with different reasoning and perspectives.
One of my favorites in this regard, is a talk by Sam Stephenson from basecamp on Turbolinks 5, which is basecamp's antidote to the JS frameworks craze. I highly recommend watching this:

My reasoning in this post will be, as mentioned, from a perspective of a small startup and why as a startup you shouldn't go with React or any JS framework for front end.

If not JS framework, what then?

This is the important stuff to begin with, that puts my reasons below into context. I'm not advocating to use vanilla JS as your framework, or any framework at all.
What I'm advocating for is a unified tool that will reduce friction between working on your backend and your frontend, and by that empower your so precious full stack developers to make their best work of delivering value for the business.

Examples for such unified tools are:

Ruby on Rails with its integrated template system
Django
Phoenix
Spring

The basic idea is to keep the mechanisms of backend and frontend closer together in a way that will reduce overhead and personnel involved in feature delivery for communication efficiency.

Eliminate friction for feature delivery

When you are small, time to market is everything. Validating your ideas, their feasibility and their utility in the real world is important.
When you are dealing with providing to businesses, especially at initial phases of your company, you need to focus on business value given more than anything else.

To do so continuously, your need to lower the friction of providing business value quickly. And not using a JS framework might be just that.

Let's take react as an example.
To master react and be able to deliver on that platform a developer have to master:

The JS environment (npm/yarn, node, etc')
- Which might be an extra load if the backend is in non-js environment.
Functional programming concepts (for pure components, why redux reducers are like they are)
- Which I'm all for, I love functional. But if the developer works on Rails or Spring, he needs to now be functional and OOP at the same time.
React crazes (OMG what are those hooks things? the last library I need only demo in hooks so I have to learn either way)
React ecosystem (redux or mobx? react-router)

A developer have so much focus and attention. Expecting him to be good with react comes at the cost of other things:

His mastery in backend engineering
His mastery in frontend by itself, you know, the actual front CSS & JS
And basically everything else he does not spend time with

That's alot to pay for. Just for potentially having smoother transition between routes by having a SPA. Or put on other words - too much payment for UX in a B2B environment where business value delivery matters more.

P.S - even worse proposition is to not to have fullstacks on the company, and resort to Backend developer and Frontend developer separately. Thus, introducing the overhead of personnel communication for every feature when you are a small startup. Yicks.

Not committing to APIs internally

When you are separating frontend and backend, you must provide APIs for the frontend to use.
Doing so early on in a startup life might be problematic. It is another point of friction, and you might find yourself committing to APIs that should die.

People also tend to use the APIs where they are not fitting, to "save" extra work.
And don't let me get started about the API design. Even if you are an expert in this field, designing an API when you are not yet sure where your business value really is? When you are still iterating with customers? This is the fast route to legacy code and code debt where you have APIs giving you a banana attached to a gorilla and a whole jungle, while you only needed the banana but some other part on the system depends on having the gorilla in this API too.

What is the long-term plan?

As a CTO, I spend alot of time thinking about this kind of stuff specifically, creating strategies for the company.

In short, what I would do in a B2B environment would be:

Start with a unified framework such as rails/django/phoenix.
Iterate quickly on business value features, usually that one developer can take full responsibility for. MVP style.
Keep iterating until something is a clear winner in the market.
Grow it as much as possible.
Be aware when you outgrew the environment - either that frontend is so important by now that you need a specialist in this field alone anyway, or that the engineering is too messy in the unified framework.
Use the Strangler pattern to move modules to an adequate JS framework.