Scholarly is building the HR operating system for higher education. We've built a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, tenure processes, leave workflows, and more. We are a venture-backed seed stage company of experienced, motivated, and collaborative folks. We are backed by leading investors in the industry and working with some of the best universities in the US.
We're looking for mid-level and senior-level full-stack candidates without about 5 or more years of experience building web applications. We write Ruby and Rails, but we are considering candidates with other stack experiences. Engineering is based in Seattle and on site in Pioneer Square. Looking to get back to a collaborative, in-office culture post-COVID? Let's chat.
Scholarly is building the HR operating system for higher education. We've built a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, tenure processes, leave workflows, and more. We are a venture-backed seed stage company of experienced, motivated, and collaborative folks. We are backed by leading investors in the industry and working with some of the best universities in the US.
We're looking for a junior- to mid-level full-stack candidate without about 5 years of experience building web applications. We write Ruby and Rails, but we are considering candidates with other stack experiences. Engineering is based in Seattle and on site in Pioneer Square. Looking to get back to a collaborate, in-office culture post-COVID? Let's chat.
As a PlanetScale MySQL user for the past 2 years, this is really exciting for the Postgres community. (Worked at a company that ran both, was a bummer our tooling didn’t match.)
Using PlanetScale for db management is like using an iPhone after being accustomed to a Treo. The experience is just better in every way.
Scholarly is building the operating system for higher education. Our vision is to build the future system of record for the industry. We are building a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, tenure processes, leave workflows, and more. We are a seed stage company of experienced, motivated, and collaborative founders. We are a seed stage company of about 10 folks. We are backed by leading investors in the industry and working with some of the best universities in the US.
We're looking for a junior- to mid-level full-stack candidate without about 5 years of experience building web applications. We write Ruby and Rails, but we are considering candidates with other stack experiences.
The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend.
If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following:
- Make the change on the server to support the new functionality. Deploy.
- Make the change on the client to adopt the new functionality. Deploy.
- Remove the old functionality from the server (optional)
Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer.
With server-authored HTML, this separate client + server deploy is not required.
There are a couple of reasons this is not convincing either:
- Other factors can often dwarf the separate deployment overhead, especially given that the deployment steps are done so often it will force the team to make it efficient and get used to it.
- There is no hard requirement for separate deployment in the first place, if we are just talking about react / spa you can deploy it in a single step. (Not saying you should)
The point is: yes there is quite a lot of overhead. From separate deployments, from separate state management and I think the big ones are often having two different programming languages and having to align schema on frontend and backend. It is hard to deny this. But then saying that because of this overhead, these kinds of apps take 2x time to code implies denying there are benefits as well, that under given circumstances can outweigh the overhead.
I think it is more interesting to assume that in some cases the benefits outweigh the cost of the overhead, and in others they do not.
Not necessarily. Most of Rails+React apps I have worked on have had the frontend code live in the same repository, and get deployed during the same step.
Yes, you have to keep API compatibility in mind when doing changes, because long-lived sessions might still exist. But has not been that much of a big deal in my experience.
Not necessarily. We write Typescript for front and back ends, using statically rendered SolidJs, skipping SSR, and hosting the corresponding Typescript in Lambdas.
Yes, we use Lambdas but the CICD pipeline is shared and currently deploys everything everywhere every time though it will be more efficient to detect and only deploy deltas (there are some minor out-of-the-box detections of non-change but further optimization is very easily possible). For now, it's more important to pursue product market fit - the deploy is ~4 min per environment which is plenty good for current purposes and could easily be parallelized among other obvious and easy wins.
OVERALL: I recommend the Serverless Framework but SSO wasn't supported at the time I started building so we use the CDK for deploying everything. The CDK stacks for the S3 bucket (etc.) and API are separate but that's a matter of factoring for clarity since it would be fine to have one big stack. For similar reasons, I factor the API and API deployment separately, alongside the WWW and WWW deployments. The entire company is a monorepo with a single command at the root that, beyond one-time account bootstrapping (which also uses CloudFormation and CDK), triggers scripts run locally or remotely to execute unit testing, deployment, and acceptance testing in a progressive multi-account deployment (on main). The CICD script installs dependencies, runs tests, identifies itself and uses that to assume account specific roles to deploy into the individual environments. This is all pretty excessive for a startup but seemed like a worthwhile and more secure foundation for actually trustworthy experimentation in delivering solutions into some of people's most sensitive private spaces and visions to go deeper.
Meta-note: I accept that the separated pieces of the infrastructure have timing deltas and that some bugs could arise out of this once we've scaled. This is never not a problem but can have diminishing windows and/or effects with investment. This can be solved either by coding the API to handle current and current-1 contracts or maintaining concurrent current and current-1 lambda version deployments, where divergence occurs. None of that contradicts a single deployment of consistent code. There are deeper solutions with greater financial efficiency but I'll need a wild success scenario before those make business sense to invest in (monoimage k8s, knative, and so on).
LAMBDA: we have built configuration that specifies the build entry points for tree shaking so that our deploy sizes are tiny and that is used by the CDK pipeline too. Our data tables are declared there too so that code and deploy share config. The Lambdas are grouped by event type (i.e. HTTP/ApiGateway, S3, Kinesis, EventBridge, etc.) and our declarations are structured according to generic Lambda defaults, a source-event-specific defaults, and a function specific declaration, allowing overrides at every level. This may sound complicated but it very cleanly organizes the configuration rather compactly, providing incredible clarity, and making scope of effect explicit and consistent.
Everything is written in TypeScript which covers internal compile-time type safety but I have written a layer of middleware for the Lambdas so that they declare their contracts (that uses AJV to validate schema to type equivalence [JSON Schema is far more specific of course]) and entry points and enforces schema compliance (engineering requirements) at all boundaries in and out of the code base (i.e. receipt of API calls in client, receipt of client requests to API, S3 data, database puts/receipts, and so on).
This got long so feel welcome to reach out (see profile) if you want more specific detail about any specific piece.
The fashionable thing for a while now has been to write your react webapp as a single app.
Here is one example of a "fullstack" react template: https://create.t3.gg/
Interesting setup. Looks like getting to a zen state like this would have required them to migrate their backend from Rails to ts at some point. I can understand the engineering decision not to do that.
yeah and it sort of sucks in comparison to most other server-authored HTML solutions, in this statement I am of course thinking of Next but I suppose various forms of suckage will be found in other solutions.
And to me both suck, compared to traditional template rendering like Jinja2 or Django Templates and those suck compared to SXML. React because of JSX and NextJS because of JSX and its assumptions about directory/file structure mapping to request routes, unless you change routing. JSX templates have that same feel, that PHP has from back in the day. Treating HTML as a string, implementing a wannabe HTML, that is not actually HTML, but slightly differen (for example the class attribute of HTML elements, or Fragment, <>) and enabling people to put JS logic inside the that string, mixing everything again, requiring to have a separate parser.
Separate parser is basically what Jinja2 has or other templating engines like Django templates. React could have used any templating engine that already existed.
But compare it to the elegance of SXML and treating HTML as the tree that is it, as structured data, enabling pattern matching on that, avoiding the need for a parser, and all other things that are in the language. Use. Structured. Data. It is so simple.
Mainstream frameworks got a lot to learn still. They are still on the Kindergarden level of treating HTML as a mere string for most parts.
> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS
I don’t grok this part. Based on my experience with RoR and JS/TS, making changes in TS-land is much easier and quicker than dealing with Ruby.
Is this just a preference/experience thing in the end? For you and your team RoR is faster/easier, so that makes it the better choice. For a different team JS/TS may be faster/easier, so that makes it the better choice?
I should have made the distinction between client-side and server-side JS/TS. Familiarity and expertise will be a main driver of productivity for a team, regardless of language/framework. For us, that's RoR.
Client-side JS however has a multiplying property, where we often need to write more server-side code to accommodate the growth in client-side code. If the client-side code is providing undifferentiated value (e.g. authoring HTML), we now have more pieces in our system to accomplish our goal (author HTML). What's been surprising to me is that you don't need to author HTML client-side to have a reactive experience. With Turbo, Stimulus, and server-rendered HTML, a great experience is possible with fewer layers.
I think the power of fat clients comes when you have different consumers of the same APIs/logic. Like a browser app or two, maybe backend services, a few task queues, etc. Then having a clean separation between client code and business logic becomes super valuable.
In my experience with SPA we got to a point where my team could go weeks, even months, without having to make changes in server code. Whole new features that were fully supported by our existing APIs because they were written as reusable APIs. If you’re having to write a bunch of Rails to support the growing client code, you probably didn’t need a separate client yet.
But when your codebase gets to that point even Rails is just a frontend really. So it’s mostly about which tradeoffs you prefer. Unfortunately I left Rails right around the time Turbo was becoming a proper thing you could use so I don’t have the best feel for what it’s like.
Thank you for writing this all up. Just curious if you ever considered switching away from Ruby? I think many people are living in parallel stacks (TS, Go, Python, Rust) and it would be interesting to hear how it’s been going more recently in that ecosystem from your perspective.
As to rendering, I’ll be honest and say that my code has moved more towards client-side (using ConnectRPC and my framework ojjs.org—-shameless plug :), but I love that you have had success with a different path. Super interesting, and thanks again!
I don't have a reason for switching away from Ruby at this point in my career. Things can always change down the line. Maintaining multiple languages at the same layer sounds like a personal nightmare to me. I'd rather learn to write PHP and have that be the only language, than to write Ruby+another language on the server-side.
We're building our company on Rails because we think it's the best choice for a young company, since it allows us to respond to customer feedback more quickly. That's what we're optimizing for right now!
Scholarly is building the HR operating system for higher education. We've built a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, tenure processes, leave workflows, and more. We are a venture-backed seed stage company of experienced, motivated, and collaborative folks. We are backed by leading investors in the industry and working with some of the best universities in the US.
We're looking for mid-level and senior-level full-stack candidates without about 5 or more years of experience building web applications. We write Ruby and Rails, but we are considering candidates with other stack experiences. Engineering is based in Seattle and on site in Pioneer Square. Looking to get back to a collaborative, in-office culture post-COVID? Let's chat.
If interested, please apply here: https://scholarly.breezy.hr/p/f3bc050f524d-software-engineer
reply