karthikksv

Orum | Full-stack developer | Remote (US only) | Full-time | https://orumhq.com/

Orum connects sales teams to their target prospects efficiently, helping them sell to their ideal customers. Using Orum's parallel dialer, sales reps can dial multiple numbers at once, and Orum's speech recognition will automatically recognize and connect reps with humans that pick up. This leads to consistent conversations, faster training, and more meetings booked.

We're a small, fully remote team that bootstrapped to almost $1M ARR in two years. Our business is young but growing quickly, and customers use our product daily (~10,000 calls/day).

This role is ideal if you like to work across the stack to make a big impact on a small team. You'll be in charge of building and owning features end-to-end, from conception to implementation to feedback/iteration. Examples include routing calls through our event-based SIP softswitch, displaying real-time call information in our UI over WebSockets, or processing streaming audio for speech recognition.

What we would love to see:

- At least 2 years of full-time, full-stack engineering experience

- Past work that shows comfort with both back-end and front-end

- Familiarity with our stack: TypeScript, Node.js, React and PostgreSQL

- You like working closely with product/sales to drive customer success

- You’re not afraid to say “I don’t know” and proactively learn new things

- You are based in the USA. This position is not open in other countries.

To apply, please reach out to jobs@orumhq.com with your resume.

Orum | Full-stack developer | Remote (US only) | Full-time | https://orumhq.com/

Orum connects sales teams to their target prospects efficiently, helping them sell to their ideal customers. Using Orum's parallel dialer, sales reps can dial multiple numbers at once, and Orum's speech recognition will automatically recognize and connect reps with humans that pick up. This leads to consistent conversations, faster training, and more meetings booked.

We're a small, fully remote team that bootstrapped to almost $1M ARR in two years. Our business is young but growing quickly, and customers use our product daily (~10,000 calls/day).

This role is ideal if you like to work across the stack to make a big impact on a small team. You'll be in charge of building and owning features end-to-end, from conception to implementation to feedback/iteration. Examples include routing calls through our event-based SIP softswitch, displaying real-time call information in our UI over WebSockets, or processing streaming audio for speech recognition.

What we would love to see:

- At least 2 years of full-time, full-stack engineering experience

- Past work that shows comfort with both back-end and front-end

- Familiarity with our stack: TypeScript, Node.js, React and PostgreSQL

- You like working closely with product/sales to drive customer success

- You’re not afraid to say “I don’t know” and proactively learn new things

- You are based in the USA. This position is not open in other countries.

To apply, please reach out to jobs@orumhq.com with your resume.

I had this same inspiration from Chris McCord's talk about LiveView ~1.5 years back, and created Purview: https://github.com/karthikv/purview - we've been using it in production at the company I work at for over a year now.

It's great to see a similar mindset here, and I hope an approach like this becomes more widely used. I appreciate how Caldera is built using React's reconciler and is centered around hooks, both of which are different than the approach Purview takes.

Two of the challenges we've experienced here:

- Transferring server-side state between processes: in production, you'll likely have multiple Node processes handling requests via the cluster module or other load balancing. If a client were to disconnect their websocket temporarily (e.g. put their laptop to sleep), they can be reconnected to a different process, which doesn't have the state of their components. As a result, you'll need some way to transfer/persist component state between processes. This same issue will also arise during deploys--you'll spawn new processes with your new code, but you don't want to disrupt existing clients, so those new processes need to load existing component state from old processes. Even more subtly, this issue can occur on page load, since two requests need to be made: one to fetch the initial page and one to initiate the websocket connection. Those two requests can be sent to two different processes/boxes.

- Working with existing client-side libraries, like selectize or date range pickers. We've opted to use the Web Component spec to create custom tags that can be sent down just like normal tags from the server, but making sure these interoperate nicely with server-side state is challenging.

Very excited to see how Caldera tackles these problems!

Dialbot | Full-stack developer | Remote (US only) | Full-time | https://dialbot.co/

We’re a small, fully remote and self-funded company that helps sales teams connect with prospects faster over the phone. Our customers use our product daily (~10,000 calls/day) and give us regular feedback. Because we’re self-funded, we avoid the hyper-growth of traditional VC startups, and we believe a few people can accomplish a great deal. We validate before we build, work on our own schedule, and execute on a focused vision.

This role is ideal if you like to work across the stack, routing calls through our event-based SIP softswitch, displaying real-time call information in our UI over WebSockets, or processing streaming audio for speech recognition. We use TypeScript/Node.js, Ruby, React, and Postgres.

What we’d love to see:

  - At least 2 years of full-time engineering experience
  - Past work that shows you’re comfortable with both back-end and front-end
  - You like working closely with product and sales to drive customer success
  - You’re not afraid to say “I don’t know,” but that doesn’t stop you from learning

Please reach out at eng@dialbot.co, and feel free to include your resume, why you’re interested, and anything else that’s relevant.

Thanks for chiming in Chris! If you don't mind, I have a few implementation questions about LiveView:

- I noticed that you said you use morphdom for LiveView. I originally started with this too, but found that the DOM diffing doesn't work well with any client-side JS that may modify the page (e.g. a date picker, a tooltip library, a custom dropdown, etc.). I ended up switching to snabbdom (https://github.com/snabbdom/snabbdom/), a virtual DOM implementation, to avoid updating parts of the page that the user doesn't directly intend to modify. This helps with client-side interop, and it also gave us a nice boost in performance. Did you run into any similar issues with LiveView? Do you still use a DOM diff rather than a virtual DOM diff?

- On that note, what's the recommend way to interop with client-side libraries like I mentioned earlier? We use the WebComponents custom-elements spec to define custom tags that encapsulate client-side JS logic (e.g. we have an <audio-player>, a <date-picker>, etc.), and then in our Purview components we can just send down these tags. We also had to provide the ability to integrate with DOM events triggered by these custom elements. Is there a recommended approach in LiveView to integrate with these libraries?

- With respect to nesting in LiveView, do you call live_render() directly within a view's render() function? Do you pass props in this call? There doesn't seem to be a differentiation between props and state for LiveView--are both consolidated into "assigns"? Hence both are mutable? I'm aware that you use immutable data structures in Erlang/Elixir, but I mean in the sense that you can assign a different value to a prop that was given to you by your parent. If this is the case, how would that work if there's a re-render and the prop passed by the parent changes?

All the business logic of the components (i.e. event handlers, lifecycle hooks, setState() calls, etc.) run on the server, unlike just the initial server-side rendering that Next.js provides. The server maintains the state of all components, and when an event occurs, the client notifies the server to run the appropriate event handler.

Perhaps I could've explained myself better. I meant that all the business logic of the components (i.e. event handlers, lifecycle hooks, setState() calls, etc.) run on the server, unlike just the initial server-side rendering that React provides. The server maintains the state of all components, and when an event occurs, the client notifies the server to run the appropriate event handler.

A common criticism I heard about React a few years back was combining JS and HTML within the same file, as opposed to having them separate. As with most decisions, I think separation is an important trade-off you need to consider: it's easier to reason about the individual, separated parts that are well-contained, but it becomes harder to reason about the system as the whole.

If you have a complex front-end and back-end with a REST API, each time you modify a server route, you need to find all instances in your client where you make an AJAX request to that route and change them appropriately. The potential for inconsistency can cause numerous bugs.

GraphQL solves this by having a very flexible and standardized server (albeit complex), giving your client access to arbitrary structured information using a query language.

Purview solves this by moving your logic to the server-side, where you can access your database directly. Because everything runs on the server, the client-server interface is abstracted away, and you don't need to worry about using GraphQL or REST. You can make database queries, contact external services, etc. directly within your components.

To keep this maintainable, you split up your page into logical, reusable components, just like you would with React, and each component now not only contains your view logic, but also the server-side logic. Given that you've decomposed your components well, this makes it easy to reason about the whole system when it comes to any part of your page.

We've been using this in production at the company I work at for about the past ~1.5 months. We've gone through a fair number of fixes and improvements throughout that time (bugs, race conditions, performance, etc.). It's definitely still a nascent project, but we're excited to continue using Purview and developing it. Would love to get your thoughts if you try it out sometime.

Yes, that was my inspiration! Chris gave a great talk about it at ElixirConf is anyone is interested in watching: https://www.youtube.com/watch?v=Z2DU0qLfPIY

Some differences compared to LiveView:

- Type-checking: there are extensive JSX typings (https://github.com/karthikv/purview/blob/master/src/types/js...) that ensure you're attaching event handlers with the correct signatures, specifying supported props, using valid HTML tags and attributes, etc. Static-typing guarantees are one of my big priorities.

- I'm not sure if LiveView intends to support nested components like React does. Having the ability to split up complex pages into components that you can nest and reuse (with mostly one-way data flow) is a key part of maintainability. I wanted to maintain a very familiar React interface, so you can pick up Purview quickly if you're comfortable with React.

You're not required to use TypeScript. As janpot mentioned, the library is transpiled prior to being published on npm, so you can use it with regular JavaScript. This is true of most TypeScript libraries.

Whenever any information needs to be saved or processed by the server, you can perform your server-side logic inline in the event handler (e.g. update the database, contact external services, etc.). There's no need to make an AJAX request and have a corresponding API route. This abstracts away the client-server interface, and you get safety guarantees with type-checking.

You're right, there's validation for the WebSocket messages sent to the server. For certain events (e.g. submit), the validation of user form data is left to you, just as you would normally be responsible for.

Higher latency connections will certainly have longer delays, but it's quite fast on a reasonable connection thanks to the persistent WebSocket, even if you're sending each letter that's being typed. We're using Purview in production at the company I work at, and we haven't had issues with input-related delays.

If you don't need to send each letter, it's recommended to not do so; the submit event object includes all form data, so you can do one final validation at the end, similar to what you'd do with a normal web server.

Dialbot | Full-stack developer | Remote (US only) | Full-time | https://dialbot.co/

We’re a small, fully remote and self-funded company that helps sales teams connect with prospects faster over the phone. Our customers use our product daily (~10,000 calls/day) and give us regular feedback. Because we’re self-funded, we avoid the hyper-growth of traditional VC startups, and we believe a few people can accomplish a great deal. We validate before we build, work on our own schedule, and execute on a focused vision.

This role is ideal if you like to work across the stack, routing calls through our event-based SIP softswitch, displaying real-time call information in our UI over WebSockets, or processing streaming audio for speech recognition. We use TypeScript/Node.js, Ruby, React, and Postgres. We appreciate knowledge of these specific technologies, but it isn’t required.

What we’d love to see:

  - Preferably 3+ years of full-time experience, but not required
  - Experience that shows you’re comfortable with both back-end and front-end
  - You like working closely with product and sales to drive customer success
  - You’re not afraid to say “I don’t know,” but that doesn’t stop you from learning

Please reach out at eng@dialbot.co and feel free to include your resume, why you’re interested, and anything else that’s relevant.

After seeing the LiveView talk, I too wanted something like it, but in a different (statically-typed) language. Last week, I released a TypeScript framework for server-side React components: https://github.com/karthikv/purview

It tries to mirror React in many ways, but like LiveView, components run on the server-side, and the client-server interface is abstracted away. So you can make database queries, contact external services, etc. directly within your components.

Ah, yes, I've used something similar in the past too. It's great for being able to see what fields you can access, but it's not guaranteed to be up-to-date with the database.

I think the biggest problem for our team is that people will have differing migrations on their respective branches. When they move around to other branches, these migrations will cause parts of the code to break, and it can be difficult to diagnose why. Enforcing the schema up front prevents these issues and helps us avoid stale/incorrect database state.

What browser/OS are you using? I just checked on Chrome and FF on my Mac, and didn't run into any issues.

Do ternary operators really make much of a performance difference compared to if-else statements? I'd imagine they're not implemented much differently when it comes down to the instruction level (you still have the conditional branch). If they do make a difference, I'd hope the browser makes the optimization. Nevertheless, as you mention, this may not be the case.

You make a good point. I'll fix this ASAP. I was also under the impression that the meta key mapped to the Windows key, but perhaps I'm wrong.

Edit: Just updated the shortcut to control + m. Let me know if you continue to experience troubles.

That's great to hear. Thanks for the feedback.

Does Greasemonkey make it easy to modify styles as well? This is simple if you can insert arbitrary JS, but it'll be annoying if you need to write JS to insert CSS for every site you want to edit. I just wanted a simple way to edit CSS without having to go to my editor or a different web page, especially for sites that I visit often. Perhaps the tool I was looking for did already exist.

Oh, no I haven't. Looks like they beat me to it in terms of features and sharing.

It seems like they could make it easier to use, though. You have to go to their custom styles page and add CSS without seeing its effects directly. Their userstyles.org website also needs some help (perhaps someone should make a stylish style for userstyles.org itself). Nevertheless, the sharing features are quite nice. I wanted to add such sharing capability myself.

Oh, that's interesting. All the content is on *.betterinternet.me, though. I feel an extension keeps the content on the owner's site, while simultaneously allowing the custom design that one wants.

Perhaps this model can provide further customization options, though.

Thanks for the kind words.

I can't foresee all scaling issues that may come to pass; for what it's worth, I can tell you that I have trust in the people behind Legit Teams to solve these problems.

In turn, I can only ask for you to try our service and see if pushing becomes a problem. I'd then love to hear your feedback via our contact page based on your experience.

We've put a lot of work into our system so far; I don't want or plan to switch over to GitHub for my private projects anytime in the prospective future.

My co-founder and I run under the philosophy that we create tools that we ourselves use. Legit Teams is no exception; we believe in the service and have no plans of discontinuing it.

I see your point. There's little I can say about handling 30,000 daily users along with support, though; what this really entails will only be determined by time if we get to that stage.

Thank you for your thoughts.

As far as I can tell, GitHub uses one git user to grant repository access to everyone. This introduces SSH key lookup problems because all GitHub members need to be authorized under this one user.

Legit Teams, by contrast, allocates an individual user per member who signs up. Thus, SSH key lookups are limited to only the keys that one person has. Correct me if I'm wrong, but I believe this circumvents the scaling issue entirely.

We created Legit Teams because we ourselves needed a service like it. As such, we don't view this as a business that's going to make us millions of dollars so much as a product that we'd love for both us and others to use. In turn, making enough money to simply handle our costs is really enough for us to keep this going.

tl;dr We're not raising prices or shutting Legit Teams down because it's not a business, but a tool that we use, and will keep using. Having others on board is a bonus! :)

In a financial standpoint, once you hit over 5 users on BitBucket, you're paying $1/user/month. With Legit Teams, you only pay for space and are not limited on either collaborators or repositories. And for me personally, the 500 MB plan is more space than I'll ever need, as only the size of my compressed .git folders count.